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Formal  Specification  and  Verification  of 
Concurrent  Programs 


Capsule  Description 


This  module  introduces  formal  specification  of  con¬ 
current  software  and  verification  of  the  consistency 
between  concurrent  programs  and  their  specifica¬ 
tions.  First,  what  one  might  want  to  be  able  to  prove 
about  a  concurrent  program  is  discussed.  Then,  a 
number  of  formal  descriptions  of  the  concept  are 
presented.  These  vary  in  their  coverage  of  the 
phenomena,  and  some  can  be  used  as  the  bases  of 
formal  specifications  of  programs.  Next,  techniques 
for  carrying  out  the  proof  of  consistency  between  the 
specification  and  the  program  are  described. 
Finally,  it  is  noted  that  some  of  these  techniques 
have  automated  tools  such  as  verifiers  associated 
with  them. 


Philosophy 


Programming  concurrent  software  is  a  complex, 
error-prone  task.  Because  of  the  inherent  nondeter¬ 
minism,  it  is  difficult  for  the  programmer  to  under¬ 
stand  the  effect  of  his  or  her  own  program.  It  is  even 
more  difficult  for  others,  such  as  the  client  and  the 
maintained  to  understand  this  effect. 

Formal  specification  of  concurrent  software  and  ver¬ 
ification  of  the  consistency  of  the  software  with 
respect  to  these  specifications  are  useful  if  for  no 
other  reason  than  they  force  a  closer  examination  of 
the  software.  Sometimes,  the  formal  models  exhibit 
aspects  of  the  nondeterministic  behavior  that  were 
not  otherwise  apparent.  Other  times,  just  the  plain 
fact  of  redundancy— the  specification  and  the  pro¬ 
gram  are  two  statements  of  the  same  thing,  but  in 
different  languages — is  what  is  useful. 

It  is  clear  that  the  cost  of  carrying  out  formal  specifi¬ 
cation  and  consistency  verification  is  high.  It  is  so 
high  that  formal  specification  and  verification  will 


not  be  used  in  a  software  development  unless  they 
are  perceived  as  reducing  the  total  cost  of  the  devel¬ 
opment.  That  is,  they  must  be  perceived  as  reducing 
the  number  of  eventual  errors,  and  the  perceived  cost 
of  the  residual  errors  were  they  not  done  must  be 
higher  than  the  cost  of  carrying  them  out. 

Consistent  with  this  utilitarian  view  is  the  obser¬ 
vation  that  very  often  the  process  of  writing  the  for¬ 
mal  specification  of  a  system  is  the  same  as  the  proc¬ 
ess  of  designing  the  system’s  functionality.  That  is, 
the  act  of  writing  the  formal  specification  is  simply 
recording  the  requirement  decisions  that  have  been 
made,  and  most  changes  taking  place  in  a  specifi¬ 
cation  before  the  first  verification  attempt  are  made 
for  the  purpose  of  getting  the  function  of  the  system 
right. 

This  philosophy  dictates  what  material  is  included  in 
this  module.  Material  is  included  if,  in  the  opinion  of 
the  author,  it  is  oriented  toward  the  practice  of  soft¬ 
ware  development,  that  is,  if  the  author  believes  that 
the  material  can  be  used  to  help  the  software  engi¬ 
neer  develop  systems  or  applications  that  exhibit 
concurrency.  Hence  material  describing  develop¬ 
ment  methods  and  specification  and  verification  en¬ 
vironments  is  included.  Theoretical  work  is  de¬ 
scribed  to  the  extent  that  it  provides  the  logical  basis 
for  practical  work.  Deep  theoretical  issues — such  as 
axiomatic  completeness,  formal  modeling  of  fair¬ 
ness,  which  are  important  in  their  own  right — are  not 
covered  here  because  they  do  not  have  an  impact  on 
the  applicable  work. 

Another  issue  dictating  what  is  covered  herein  is  the 
simple  fact  that  as  this  module  is  being  written,  the 
field  is  expanding!  Indeed,  the  release  of  this  module 
has  been  delayed  more  than  once  by  the  discovery  of 
recent  new  material.  An  arbitrary  decision  was  taken 
to  release  the  module  now  with  what  is  already  in  it. 
Surely,  the  document  is  thick  enough! 
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Finally,  there  is  still  other  not-so-recent  material  that 
is  consistent  with  the  philosophy  and  is  nevertheless 
rot  covered  in  more  detail  than  a  mere  mentioning 
with  a  bibliographical  citation.  These  citations  point 
to  approaches  that  are  so  similar  to  approaches 
covered  in  detail,  that  not  enough  would  be  gained 
by  discussing  them  in  detail.  The  choice  of  which 
approach  to  cover  among  similar  approaches  was  ar¬ 
bitrary,  reflecting  what  was  known  first  to  the  au¬ 
thor,  and  should  not  be  construed  as  saying  that  the 
presented  approach  is  any  better  than  the  others. 

In  any  case,  this  module  discusses  neither  VDM 
[Bekic74]  nor  Z  [Hayes87]  because 

1. VDM  is  covered  in  another  module 
[Pedersen89]  in  detail,  and 

2.  neither  is  really  intended  for  use  in  deal¬ 
ing  with  concurrency;  they  both  aim  at 
treating  programs  as  functions,  and  most 
concurrent  programs,  being  nonhalting 
systems,  are  just  not  describable  as  func¬ 
tions. 


Objectives 


The  student  who  has  absorbed  the  material  of  this 

module  can  be  expected  to 

Know 

•  of  the  various  tools  and  environments  of 
tools  for  carrying  out  specification  and 
consistency  verification 

Comprehend 

•  the  basic  terminology  of  concurrency 

•  the  various  properties  that  concurrent 
systems  may  or  may  not  satisfy  and  the 
meanings  of  and  differences  between 
these  properties 

•  the  various  formal  models  of  concur¬ 
rency  and  their  relations  to  each  other 
and  their  coverage 

•  the  various  formal  specification  lan¬ 
guages 

•  the  methods  for  proving  programs  con¬ 
sistent  with  specifications 

Apply 

•  at  least  one  of  the  specification  lan¬ 
guages  to  a  problem  of  moderate  size 

Analyze 

•  specifications  in  any  of  the  various  speci¬ 
fication  languages 


•  verifications  of  consistency  carried  out  in 
any  of  the  proof  systems 

Synthesize 

•  a  specification  of  a  program  in  at  least 
one  specification  language 

•  a  verification  of  the  consistency  of  a  pro¬ 
gram  to  specifications  in  the  above  lan¬ 
guage 

Evaluate 

•  the  coverage  of  any  of  the  above  or  new 
formal  models,  specification  languages, 
and  environments 


Prerequisite  Knowledge 


The  student  should  be  fully  familiar  with  the  mate¬ 
rial  of  the  curriculum  module  Formal  Verification  of 
Programs  [Berztiss88]  and  of  all  of  its  prerequisites, 
especially  those  of  programming  and  mathematical 
maturity.  The  student  should  also  be  familiar  with 
the  of  the  curriculum  modules  Concepts  of  Concur¬ 
rent  Programming  [Bustard90]  and  Languages  and 
System  Support  for  Concurrent  Programming 
[Fe!dman901  and  their  support  materials. 

It  is  useftil,  but  not  essential,  to  have  some 
familiarity  with  the  material  in  the  curriculum  mod¬ 
ules  Formal  Specification  of  Software  (Berztiss87], 
Software  Specification:  A  Framework  {Rombach87], 
and  Software  Development  using  VDM 
[Pedersen89], 
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Module  Content 


Outline _ 

I.  Unifying  Model 

II.  Properties  of  Concurrent  Programs 

1.  Safety  Properties 

a.  Deadlock  Freeness 

b.  Mutual  Exclusion 

c.  Data  Security 

d.  Proper  Termination 

e.  Partial  Correctness 

2.  Liveness  Properties 

a.  Fairness 

b.  Receiving  Requested  Data 

c.  Sent  Message  Will  Arrive 

d.  Each  Request  Serviced 

e.  Termination 

f.  Total  Correctness 

3.  Others 

III.  Formal  Models 

1.  Operational  —  NDISM 

a.  Description  of  NDISM  by  Program 

b.  Formal  Mathematical  Descriptions  of 
NDISMs 

c.  Redundant  Specification  of  Properties 

d.  Formal  Verification  of  Redundantly 
Specified  Properties 

e.  Graph  Models  of  Concurrent  Computation 

2.  Axiomatic 

3.  Temporal  Logic 


4.  Denotational 

5.  Comparisons  of  the  Coverage  of  the 
Approaches 

IV.  Actual  Specifications  of  Software 

1.  Operating  System  Security 

2.  Database  Integrity 

3.  Protocols 

4.  Other  Problems 

V.  Doing  the  Verifications 

VI.  Specification  Languages  and  Verification 
Environments 

1.  AFFIRM 

2.  FDM 

3.  Gypsy 

4.  HDM 

5.  P-NUT 

6.  SARA 

7.  PAISLey 

8.  STATEMATE 

9.  Process  Algebras 

10.  ASTRAL 

VII.  Current  Status 
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Annotated  Outline _ 

I.  Unifying  Model 

For  the  purpose  of  unifying  the  discussion  of  all  of  the 
formal  models  of  concurrency  covered  in  this  module 
and  for  providing  a  basis  tor  comparing  them  with  each 
other,  this  module  uses  the  formal  model  of  compu¬ 
tation,  known  as  the  Nondeterministic  Information 
Structure  Model  (NDISM)  [Wegner68],  It  is  a  state 
machine  formalism  in  which  the  content  of  the  state  is 
left  unspecified  but  can  be  made  as  simple  or  as  com¬ 
plex  as  desired.  The  same  pictorial  version  of  this 
formal  model  is  used  in  the  textbook  Programming 
Language  Structures  [Organick78]  and  in  “A  Visual 
Execution  Model  for  Ada  Tasking’’  [Dillon92]. 

In  NDISMs,  concurrency  is  modeled  by  supposing  the 
existence  of  process  items  in  the  state  and  nondeter- 
ministically  selecting  one  such  process  to  execute  one 
instruction  at  each  state  transition.  In  other  words,  con¬ 
currency  is  modeled  by  interleaving  process  computa¬ 
tions  at  the  granularity  of  the  single  instruction. 

For  the  purpose  of  establishing  the  notation  used  in  this 
module,  the  basic  definitions  given  in  the  support 
materials  are  repeated  in  this  section. 

The  formal  model  is  that  of  a  nondeterministic  infor¬ 
mation  structure  model  (NDISM)  [Wegner68]. 

Af=(/,/0,  F)  is  an  NDISM  if  and  only  if 
1./ is  a  countable  set 

2  -/0C/ 

3.  F.i-*nn 

The  elements  of  the  set  I  are  called  snapshots. 

A  possibly  infinite  sequence  C=(Sq,  . . .  . . . )  is 

a  computation  in  an  NDISM  Af=(f,  /0,  F)  if  and  only  if 

1.  \fSj  in  C,  s«  / 

2.  J0e/0 

3  .Vi>0.steF(s^l) 

4.  C  is  a  proper  initial  subsequence  of  no  other  se¬ 
quence  meeting  conditions  1-3 

Note  that  the  1th  snapshot  is  one  of  the  elements  yielded 
by  applying  the  transformation  F  to  the  i-l,h  snapshot 
Herein  lies  the  nondeterminism;  in  each  step  of  each 
computation,  the  next  step  is  chosen  from  among  pos¬ 
sibly  several  candidate  next  steps.  Condition  4  assures 
that  no  finite  subcomputation  of  a  computation  is  con¬ 
sidered  a  computation;  thus  infinite  computations  must 
be  carried  out  forever. 

Because  of  this  nondeterminism,  one  may  view  an 
NDISM  M  as  giving  rise  to  a  tree  of  potential  computa¬ 
tions  from  each  initial  snapshot,  as  Figure  1  illustrates. 
(All  figures  and  tables  are  gathered  at  the  end  of  this 
document  starting  on  page  100.)  The  point  in  the  far 


left  represents  an  initial  snapshot,  and  each  forking 
point  represents  the  choice  of  successor  snapshots.  A 
computation  is  a  path  from  left  to  right  along  the  tree 
Note  that  the  nondeterminism  that  represents  concur¬ 
rency  is  different  from  the  traditional  automata 
theoretic  nondeterminism  [Hopcroft79],  Automata 
theoretic  nondeterminism  is  an  abstraction  of  either  ( 1 ) 
trying  all  possible  computations  at  once  until  one  is 
found  that  gives  an  answer  to  the  problem  that  the 
automaton  solves  or  (2)  always  choosing  the  right  suc¬ 
cessor  snapshot  that  leads  directly  to  an  answer  In 
concurrency,  one  is  choosing  only  one  path,  ano  there 
is  no  notion  that  any  one  is  more  correct  than  the  other. 

A  computation  C=(r0, . . .  . . .  )  in  an  NDISM 

M=(1, 10,  F)  is  said  to  halt  at  snapshot  sn  if  and  only  if 

1.  sn  is  in  C 

2.  F(rn)=0 

Note  that  Condition  4  of  the  definition  of  a  compu¬ 
tation  guarantees  the  uniqueness  of  r„;  it  is  the  fust  and 
only  snapshot  in  C  that  can  satisfy  Condition  2  of  the 
same  definition. 

The  execution  of  a  program  p  in  the  presence  of  input  i 
is  a  computation  beginning  from  an  initial  snapshot  s0, 
which  contains  some  representation  of  p  and  i.  For  a 
given  p  and  i,  there  may  be  more  than  one  compu¬ 
tation,  some  of  which  hall  and  some  of  which  do  not 
halt.  If  a  computation  halts,  the  computation  is  said  to 
yield  an  output,  namely  a  portion  of  the  final  snapshot 
designated  as  the  output  o.  There  are  some  special 
situations  that  have  special  names. 

•  If  for  all  input  i,  all  computations  arising  from  i  and 
a  program  p  halt,  then  p  is  said  to  be  a  halting 
program. 

•  If  for  all  input  i,  all  computations  arising  from  i  and 
a  program  p  do  not  halt,  then  p  is  said  to  be  a 
looping  program. 

•  If  for  all  input  i,  the  initial  snapshot  built  from  i  and 
a  program  p  gives  rise  to  at  most  one  computation, 
then  p  is  said  to  be  a  deterministic  program. 

Note  that  a  program  that  is  not  a  halting  program  is  not 
necessarily  a  looping  program,  as  it  may  have  some 
computations  that  do  halt  and  some  that  do  not  halt 

A  deterministic  halting  program,  which  is  actually  not 
the  subject  of  this  module,  is  said  to  implement  a 
function  because  for  each  input,  the  program  yields  a 
unique  final  snapshot  from  which  a  unique  output  may 
be  extracted.  A  deterministic  non-halting  program  is 
said  to  implement  a  partial  function;  one  assigns 
undefined  as  the  result  of  the  function  for  those  inputs 
giving  rise  to  non-halting  computations.  A  nondeter¬ 
ministic  halting  program  can  also  be  considered  a  func¬ 
tion,  on  the  inputs  to  sets  of  all  possible  outputs  for  the 
inputs.  A  nondeterministic  non-baiting  program  can 
likewise  be  considered  a  function  to  sets  some  of  which 
may  contain  undefined  as  elements  corresponding  to 
non-halting  computations. 
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A  looping  program  considered  as  a  function  is  a  very 
uninteresting  function,  as  all  of  its  results  are  undefined 
or  singleton  sets  containing  undefined.  More  usually, 
looping  programs  are  called  systems.  Normally  an 
operating  system  is  supposed  to  be  a  looping  program. 
In  reality,  operating  systems  are  really  non-halting, 
non-looping,  nondeterministic  programs.  Their  halting 
computations  are  considered  erroneous!  A  challenge  of 
program  verification  is  to  prove  that  programs  that  are 
supposed  to  implement  functions  do  and  that  programs 
that  are  supposed  to  implement  systems  do. 

In  the  usual  formal  model  of  concurrency,  the  snap¬ 
shots  contain  some  structure  representing  processes, 
each  of  which  is  in  one  of  the  three  abstract  statuses, 
awake,  asleep,  and  terminated.  When  F  is  applied  to  a 
snapshot  j.,  the  resulting  set  of  snapshots  contains  one 
element  for  each  awake  process  in  sr  The  result  snap¬ 
shot  for  a  given  process  shows  the  changes  caused  by 
having  that  process  execute  one  instruction.  Thus 
choosing  an  element  of  F(st)  amounts  to  selecting  one 
process  in  s-  to  have  it  execute  one  instruction.  The 
formal  model  then  models  the  concurrency  with  an  in¬ 
terleaving  at  the  level  of  one  instruction. 

The  question  can  be  asked  “Is  this  interleaving  model 
an  accurate  depiction  of  concurrency  that  may  include 
genuine  parallelism?"  To  see  that  the  answer  is  “Yes!” 
observe  that  if  the  processes  shared  no  data  objects 
(communications  channels  included)  then  no  process 
can  affect  another,  and  the  results  of  a  computation 
involving  these  (independent)  processes  is  indistin¬ 
guishable  from  those  of  any,  even  serial,  ordering  of 
the  processes.  The  only  way  processes  can  affect  each 
other  is  through  shared  data  objects.  As  an  example  of 
access  to  shared  data,  consider  now  two  processes, 
being  run  by  two  processors,  trying  to  write  to  the  same 
memory  location.  In  all  machines  known  to  this  au¬ 
thor,  there  is  some  hardware  arbiter  that  prevents  two 
processors  from  writing  to  the  »aiue  memory  location 
at  the  same  time  and  serializes  these  writes  so  that  one 
is  finished  entirely  before  the  other  begins.  The  net 
effect  will  be  the  effect  of  the  second  write.  This  arbit- 
ing  occurs  on  every  device  and  guarantees  that  every 
possible  interaction  of  otherwise  independent  processes 
is  serialized  to  the  level  of  the  machine  instruction. 
Thus,  any  possible  concurrent,  even  parallel,  behavior 
can  be  simulated  by  an  interleaving  model  that  inter¬ 
leaves  at  the  instruction  level  This  unit  of  interleaving 
is  called  the  granularity  of  the  interleaving.  Thus,  it  is 
legitimate  to  use  an  interleaving  formal  model  to  repre¬ 
sent  concurrency. 

II.  Properties  of  Concurrent  Programs 

Recall  the  discussion  about  safety  and  liveness 
properties  in  [Bustard90].  Here,  this  discussion  is 
recast  in  terms  of  the  NDISM  model.  Later,  when 
other  formulations  of  these  properties  are  given  in 
other  formal  models,  these  formulations  will  be  seen  as 
expressing  the  same  ideas. 


Any  property  that  one  may  wish  to  verify  about  con¬ 
current  programs  may  be  categorized  according  to  the 
nature  of  the  property  involved  The  property  may 
usually  be  classified  as  a  safety  property  or  a  liveness 
property.  The  difference  between  them,  as  described  in 
detail  below,  is  in  the  nature  of  the  quantifiers  used 
over  snapshots  in  their  formal  expression.  This  classi¬ 
fication  captures  most  of  what  is  desired  to  prove. 
There  are  other  properties  that  cannot  be  classified  as 
either  safety  or  liveness  properties. 

For  each  property  described  below,  enough  of  a  formal 
statement  is  given  to  show  why  it  is  a  properly  of  the 
type  churned.  The  only  quantification  shown  explicitly 
is  that  over  snapshots.  The  assertions  in  the  scopes  of 
these  quantifiers  are  given  in  English.  These  assertions 
may  obviously  contain  implicit  quantifiers,  but  none  of 
them  arc  over  snapshots;  rather  they  are  over  elements 
within  a  snapshot.  Such  quantification  does  not  change 
the  nature  of  the  property. 

All  the  kinds  of  properties  are  described  in  terms  of  the 
NDISM  model  introduced  earlier. 

1.  Safety  Properties 

A  safety  property  is  one  that  can  be  expressed  in  an 
assertion  involving  universal  quantification  over 
snapshots.  Examples,  in  the  abstract,  of  such 
properties  are  those  that  can  be  expressed  thusly 

•  P  is  true  in  all  snapshots,  i.e.,  Vs  in  C(P(s)) 

•  P  never  happens,  i.e..  Vs  in  C (~.F(s)) 

•  Whenever  P  happens  Q  is  true,  i.e, 
VsinC(P(s)=>(2(s)) 

Note  that  the  C  mentioned  is  implicitly  universally 
quantified  over  all  computations  of  the  program 
about  which  Uie  property  is  being  proved  The  pro¬ 
gram  together  with  any  set  of  input  files  determines 
an  initial  snapshot  which,  in  turn,  determines  a  set  of 
computations  of  that  initial  snapshot. 

Historically  these  properties  are  quite  familiar,  be¬ 
cause  they  can  be  demonstrated  by  inductive  means 
[King80,  Cousot82,  Manna72].  That  is,  they  are 
shown  to  hold  for  initial  snapshots  and  then  they  are 
shown  to  be  preserved  by  the  transition  function  F 
of  the  NDISM.  They  are  very  otten  expressed  with¬ 
out  the  quantifier,  relying  on  implicit  universal 
quantification  of  free  variables. 

a.  Deadlock  Freeness 

In  no  snapshot  are  all  processes  asleep  or  ter¬ 
minated,  i.e.,  VsinC,  there  is  at  least  one  awake 
process  in  s. 

b.  Mutual  Exclusion 

In  no  snapshot  are  two  or  more  processes  in  their 
critical  region,  i.e.,  VsinC,  if  one  process  in  s  is 
in  its  critical  region  then  no  other  process  in  s  is 
in  its  critical  region. 
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c.  Data  Security 

In  no  snapshot  are  there  unauthorized  disclosures, 
i.e.,  Vjin  C,  if  a  process  in  s  is  wriung  data  to  a 
file  in  s,  then  the  data  it  is  writing  is  from  an 
object  in  s  to  which  the  process  has  access. 

d.  Proper  Termination 

If  and  when  the  computation  halts,  then  all  proc¬ 
esses  are  terminated  (i.e.,  none  are  asleep),  i.e., 
Vs  in  C,  if  F(s)=0  then  no  process  in  s  is  asleep. 
Note  that  if  F(s)=0,  then  no  process  in  s  can  pos¬ 
sibly  be  awake.  Were  there  an  awake  process  in 
s ,  it  would  be  selected  for  execution  to  yield  a 
next  snapshot. 

e.  Partial  Correctness 

If  at  the  beginning  of  the  computation,  the  input  is 
legitimate,  and  if  the  computation  halts,  then  the 
output  is  what  is  required  In  other  words,  if  at 
the  beginning  of  the  compulation,  the  input  is 
legitimate,  then  in  any  final  snapshot,  the  output 
is  as  required.  In  other  words,  if  the  input  of 
s0inC  satisfies  input  condition  /  and  Vs,inC,  if 
F(s,)=0,  then  the  output  of  st  satisfies  output  con¬ 
dition  0. 

Alternatively  if  at  the  beginning  of  the  compu¬ 
tation  the  input  is  in  the  range  of  the  function  to 
be  implemented  and  if  the  computation  halis,  then 
the  output  is  the  result  of  applying  the  function  to 
the  input,  i.e.,  if  the  input  i  of  r0inC  is  in  the 
domain  of  the  function /,  and  VSjinC,  if  F(s]}=0, 
then  the  output  o  of  sf  is  such  that  oefii). 

Note  that  the  second  definition  accommodates 
nondeterministic  functions. 

2.  Liveness  Properties 

A  liveness  property  is  one  that  can  be  expressed  in 
an  assertion  involving  existential  quantification  over 
snapshots.  Examples  ot  such  properties  are  those 
that  can  be  expressed  as  the  following: 

•  There  exists  a  snapshot  in  which  P  is  true,  i.e., 
3sin  C(F(s)) 

•  There  exists  a  snapshot  in  which  P  is  not  true, 
i.e.,  3smC(->P(s)) 

•  Whenever  P  happens  then  at  some  later  time  Q  is 
true,  i.e..  Vs,  in  C(F(s)3(3^in  C  (j>i/\Q(Sj)))) 

The  difficulty  with  liveness  properties  is  that  they 
cannot  be  demonstrated  directly  by  the  familiar  in¬ 
ductive  methods.  They  must  be  demonstrated  by 
showing  that  each  step  in  the  computation  brings  the 
computation  closer  to  a  snapshot  in  which  the  de¬ 
sired  property  is  true.  One  typically  finds  a  well 
ordering  (that  is,  a  partial  ordering  with  a  least 
element)  [Manna74]  and  program  variables,  or  a 
function  thereof,  such  that  the  variable  or  function 
values  are  related  by  that  well  ordering  such  that 


1.  within  every  n  steps,  with  n  fixed,  the  vari¬ 
ables  decrease  with  respect  to  that  ordenng, 
and 

2.  that  the  variable  has  reached  the  minimum  im¬ 
plies  that  the  desired  property  holds 

Since  a  well  ordered  set  has  a  least  element,  it  is 
ineviiable  that  the  computation  will  eventually  reach 
a  snapshot  with  the  desired  property  One  typically 
shows  lhai  the  variables  decrease  by  appeal  to  some 
safety,  i.e..  invariant,  properly  There  is  the  need  for 
considerable  creativity  in  finding  variables,  some 
function  of  them,  and  a  relation  over  Ihe  range  of 
that  function  that  allow  one  to  carry  out  the  proof  It 
should  be  clear  from  the  complexity  of  the  above 
description  that  showing  hveness  is  considered 
much  harder  than  showing  safety 

Because  proofs  of  hveness  properties  usually  require 
showing  some  invariant  properties  along  the  way,  n 
is  no  problem  if  the  existential  quantifier  is  within 
the  scope  of  a  universal  quantifier 

a.  Fairness 

In  all  snapshots  for  all  ready  processes,  eventually 
the  process  will  become  running;  i  e„  Vs,  in  C,  for 
all  n,  a  ready  process  in  s.  3 sj  in  C.  such  that  j  >i 
and  n  is  running  in  sy 

b.  Receiving  Requested  Data 

In  all  snapshots,  if  a  request  for  information  has 
been  received,  then  there  is  a  future  snapshot  in 
which  this  informauon,  if  legitimate  to  do  sc.  is 
released,  i.e.,  Vs,inC,  if  fl  in  s,  has  requested 
data  from  an  object  o  in  s,  and  n  has  access  to  the 
object  o,  then  3 s  in  C,  such  that  j  >i  and  11  in  s; 
receives  the  data 

c.  Sent  Message  Will  Arrive 

In  all  snapshots,  if  a  message  is  sent  then  in  some 
future  snapshot,  the  message  will  be  received,  i.e., 
Vs,  in  C,  if  a  message  m  is  sent  in  5,  then  3 Sj  in  C, 
such  that  j  >i  and  m  is  received  in  sy 

d.  Each  Request  Serviced 

In  ail  snapshots,  if  a  sendee  is  requested,  then 
there  is  a  future  snapshot  in  which  this  request  is 
granted,  i.e  ,  Vs,  in  C,  a  service  is  requested  in  s,, 
then  IjyinC,  such  that  j>i  and  the  request  is 
granted  in  s;. 

e.  Termination 

Eventually  the  computation  halls,  i.e.,  3s,inC, 
such  that  F(sy)=0 

f.  Total  Correctness 

If  at  the  beginning  of  die  computation  the  input  is 
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legitimate,  then  eventually  the  computation  halts 
and  the  output  is  what  is  required,  i.e.,  if  the  input 
of  s0inC  satisfies  input  condition  l,  then  3.v,  in  C, 
such  that  F(sl)=0  and  the  oi"put  of  <(  satisfies 
output  condition  O. 

Alternatively  if  at  beginning  of  the  compu¬ 
tation  the  input  is  in  the  range  of  the  function  to 
be  implemented,  then  the  computation  lialLs  and 
the  outrut  is  the  result  of  applying  the  function  to 
the  input,  i.e.,  if  the  input  i  of  s0  tn  C  is  in  the 
■'omain  of  the  function  /,  then  3s  in  C,  such  that 
F(  J;)=0  and  the  output  o  of  s]  is  such  that  oe J{i). 

3.  Others 

These  properties  cannot  be  described  either  as  uni¬ 
versal  quantification  over  unquantified  snapshot 
assertions  or  as  possibly  universally  quantified  ex¬ 
istential  quantification  over  snapshot  predicates.  A 
non-exhaustive  list  follows: 

•  P  happens  infinitely  often  —  for  all  snapshots, 
there  exists  a  later  snapshot  such  that  P ,  i.e., 
Vr(  in  C(3s]  in  C (j>i/\P(s))) . 

•  Whenever  P  happens,  within  rt  steps,  Q  happens, 
i.e.,  Vs(  in  C(P(si)z>3s}  in  C  {j  >i+n*Q(Sj))) . 

•  Whenever  P  happens,  within  x  seconds,  Q  hap¬ 
pens,  that  is,  Vs(  in  m  C 

(\Time( Sj >-  7i»ie(  j -)|£jr  a  . 

•  The  transition  satisfies  constraint  P  [Locasso80, 
Scheid86a]  —  every  transition  satisfies  P,  i.e., 
VrI,.rl+|inC(/>(jJ,j;)) 

III.  Formal  Models 

Ihis  section  describes  several  well-known  formal 
models  of  concurrency  Each  of  these  is  intended  for 
and  has  been  used  for  formal  verification  of  properties 
of  concurrent  programs.  A  later  section  details  the 
proofs  that  have  been  done  with  each  In  this  section, 
each  is  described  in  terms  of  its  relation  to  the  NDISM 
model  described  in  Section  I.  Two  considerations  dic¬ 
tated  the  choice  of  the  NDISM  as  the  model  of  Section 
I. 

1  The  NDISM,  which  turns  out  to  be  an  operational 
model,  is  one  of  die  most  fundamental  in  that  it 
can  capture  all  known  phenomena,  it  corresponds 
tc  what  is  lmplementablc  and  thus  what  will  be 
founJ  in  implementations,  and  it  can  be  used  to 
model  ail  the  others. 

2  In  fact,  models  similar  to  NDISMs  are  used  by 
other  authors  to  describe  their  formal  systems. 

For  each  formal  model,  the  description  includes  defini¬ 
tions  of  the  basics  and  a  brief  discussion  of  what  can  be 
proved  using  it 

I .  Operational  —  NDISM 

Operational  models  attempt  to  specify  the  system 


behaviorally,  that  is  by  describing  what  happens  dur¬ 
ing  its  computations,  in  every  operational  model  is 
lurking  an  NDISM  of  some  form.  That  is,  in  every 
operational  model  one  will  find  a  description  of  die 
snapshots  or  suites,  a  description  of  initial  snapshots, 
and  a  description  of  how  to  obtain  a  next  snapshot 
from  the  current  one.  Some  operauonal  models  are 
described  with  programs  and  others  are  described  by 
other  formal  means. 

a.  Description  of  NDISM  by  I^ogram 

When  one  uses  a  program  to  describe  an  opera¬ 
tional  model,  one  is  in  effect  writing  an  inter¬ 
preter  program  which  computes  from  initial  snap 
shots.  Ihe  snapshots  are  described  by  die 
declarations  of  die  data  structures  needed  by  the 
interpreter;  the  initial  snapshots  are  described  un- 
pitcidy  as  that  configuration  of  the  snapshot  data 
structures  that  are  accepted  by  the  interpreter  as 
being  legitimate  to  begin  a  amputation  The 
transformation  is  defined  implicitly  as  what  the 
interpreter  does  in  modifying  one  snapshot  into 
the  next  Usually,  in  the  interpreter  there  is  a 
single  identifiable  point  at  which  the  configura¬ 
tion  of  die  snapshot  data  structures  are  considered 
to  form  a  new  snapshot,  in  a  normal  interpreter 
this  would  usually  be  at  the  top  of  the  loop  in 
which  instructions  are  fetched  and  executed  Ex¬ 
amples  of  these  kinds  of  definitions  are  the  orig¬ 
inal  and  several  later  LISP  definitions 
[McCarthy65]  [Reynolds72]  and  the  definition  of 
Euler  [Wirth66]  Such  definitions  arc  in  general 
hard  to  use  for  verification  The  transformation 
function  is  only  implicit.  Thus,  one  is  forced  to 
use  the  formal  methods  of  verifying  normal,  se¬ 
quential  program  behavior  [8erz?iss88]  just  to 
show  that  the  interpreter  is  doing  what  it  is 
claimed  to,  so  that  one  can  show  that  die  inter¬ 
preted  program  is  doing  what  it  is  claimed  to  An 
NDISM  in  which  the  transformadon  funcuon  is 
expressed  more  directly  is  preferable 

b.  Formal  Mathematical  Descriptions  of 
NDISMs 

The  other  languages  for  writing  NDISMs  have 
more  mathematical  notations  for  expressing  the 
transformation  in  a  manner  that  allows  a  more 
direct  use  of  parts  of  its  definition  in  proofs 
These  languages  provide  some  notauon  for  de¬ 
scribing  the  set  of  all  snapshots  and  the  set  of 
initial  snapshots  as  a  subset  of  the  set  of  all  snap¬ 
shots  In  these  languages,  snapshots  have  been 
described  as  trees  with  labeled  nodes  and/or 
edges,  lists,  ordered  tuples,  sets,  functions,  etc. 

There  are  a  number  of  different  ways  of  speci¬ 
fying  the  F  of  a  particular  NDISM  These  ways 
may  be  classified  by  a  number  of  different  dimen¬ 
sions.  There  arc  direct  methods  in  which  V  itself 
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is  described  and  there  are  indirect  methods  in 
which  a  program  P  which  computes  F  is  de¬ 
scribed.  A  program  P  computes  F  if  and  only  if 
each  computation  of  P  is  a  computation  induced 
by  F  and  vice  versa. 

(i)  Direct  Description  of  F  of  NDISM 

Within  the  former  methods,  there  are  two  dif¬ 
ferent  approaches  to  directly  describing  F : 

•  Write  a  function  which  given  a  snapshot 
yields  the  set  of  next  snapshots,  and 

•  write  a  predicate  satisfied  by  legitimate 
pairs  of  successive  snapshots. 

In  these  approaches  of  direct  specification  of  F, 
it  is  easy  to  see  the  individual  snapshot  transi¬ 
tions  but  hard  to  visualize  a  program  P  com¬ 
puting  the  transitions.  It  may,  however,  be  ex¬ 
plicitly  stated  along  with  the  NDISM  that  the 
transition  F  is  not  intended  to  represent  primi¬ 
tive  or  indivisible  transitions  of  the  specified 
system.  In  this  case,  one  cannot  know  the  indi¬ 
vidual  primitive  snapshot  transitions.  Some 
examples  of  languages  of  the  first  kind  arc 
VDL  [Lucas69,  Wegner72),  and  SPECIAL 
[Silverberg79],  Some  examples  of  languages  of 
the  second  kind  are  InaJo™3  [LocassofiO, 
Scheid86a],  and  AFFIRM  [Thompsons  1], 

(ii)  Indirect  Description  of  F  of  NDISM 

Within  the  latter  method,  any  programming 
language,  either  of  the  implemented  or 
gedanken  variety  can  be  used.  In  the  gedanken 
variety,  e.g„  the  language  of  the  Euler  defini¬ 
tion  [Wirth66],  one  finds  languages  with  sets  as 
data  types  and  r.ot-so-easily-implememed  set 
theoretic  operations,  including  quantification, 
as  operations.  In  these  methods  of  writing  a 
program  P,  the  program  computing  F  is  ex¬ 
plicit,  but  it  is  hard  to  see  the  individual  transi¬ 
tions.  Indeed,  it  is  usually  left  unspecified  as 
to  what  are  the  indivisible  operations  in  order 
to  give  the  compiler  the  right  to  choose  the 
primitive  operations.  For  example,  for 

x : =x+l 

the  indivisible  steps  depend  on  the  machine  for 
which  the  code  is  generated.  Usually  the  code 
is  something  like 

LD  l,  X 

AD  1,-1 

ST  l,x  , 

resulting  in  three  indivisible  steps  for  the  as¬ 
signment  On  the  other  hand,  if  the  machine 
has  a  special  instruction  for  incrementing  a 


memory  location  by  one,  the  statement  might 
indeed  be  compiled  into  a  single  indivisible 
step, 

+  1  X  . 

Lamport  [LamportBOa]  has  suggested  a  way  to 
indicate  indivisible  operations  at  the  source 
language  level  by  use  of  angle  brackets,  “<,  >", 
around  indivisible  steps.  A  decomposition 
equivalent  to  the  first  translation  above  would 
be  specified  as 

<x :  =<<x>+l»  , 

while  a  decomposition  equivalent  to  the  second 
translation  would  be  specified  as 

<x:=x+l>  . 

c.  Redundant  Specification  of  Properties 

In  all  of  these  methods  of  specifying  F,  it  is  some¬ 
times  allowed  to  specify  non-algorithmic 
properties  as  a  redundant  description  of  what  the 
computation  is  supposed  to  be  doing.  For  ex¬ 
ample,  one  may  have  specified  in  F  a  database 
system  in  which  each  transition  represents  an  up¬ 
date  of  or  a  query  to  the  database.  The  redundant 
description  might  describe  integrity  properties 
that  the  data  of  the  database  always  satisfy.  The 
purpose  of  this  redundant  specification  is  to  allow 
checking  or  even  verification  that  the  operations 
as  specified  preserve  these  properties. 

Redundant  Properties 

In  the  direct  methods  of  specifying  F,  one  might 
give  assertions  that  are  to  be  satisfied  by  initial 
snapshots,  by  all  snapshots,  and  by  final  snap¬ 
shots.  In  the  indirect  methods,  one  might  give  a 
number  of  program  point-assertion  pairs  such  that 
every  time  execution  goes  through  a  point,  its 
assertion  is  to  hold.  For  example,  consider  a  pro¬ 
gram  to  sort  the  elements  of  an  array  into  ascend¬ 
ing  order.  Attached  to  the  entry  point  of  the  out¬ 
ermost  loop,  which  steps  through  the  array  in  as¬ 
cending  order,  might  be  an  assertion  claiming  that 
the  portion  of  the  array  between  the  beginning 
and  the  element  indexed  by  one  less  than  the  cur¬ 
rent  loop  index  value  are  sorted  and  are  less  than 
all  elements  in  the  rest  of  the  array. 

Many  of  the  methods  of  verifying  what  systems 
or  programs  do  consists  in  verifying  that  the  F  or 
P  are  consistent  with  their  redundant  descriptions. 
Typically  for  the  direct  methods  of  specifying  F, 
an  inductive  approach  is  taken  to  prove  that  a 
specified  property  holds  in  all  snapshots.  It  is 
shown  that  the  property  holds  in  all  initial  snap¬ 
shots,  and  then  it  is  shown  that  if  the  property 
holds  in  any  snapshot  S,  then  it  holds  in  any  snap¬ 
shot  yielded  by  applying  F  to  S. 


’ina  Jo  is  a  trademark  of  Uniays  Corporation. 
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Safety  Properties 

In  principle  any  expressible  property  can  be 
proved  in  these  operational  models.  However, 
because  of  the  inductive  nature  of  the  typical 
proof,  they  have  been  used  primarily  for  safety 
properties.  It  is  quite  straightforward  to  express  a 
safety  property  as  an  assertion  that  must  be  true  in 
every  snapshots.  One  proves  the  property  induc¬ 
tively  by  showing  that  all  initial  snapshots  satisfy 
ne  assertion  and  then  showing  that  if  it  holds  at 
any  snapshot,  it  will  hold  again  at  any  next  snap¬ 
shot.  Showing  the  latter  amounts  to  showing  that 
the  transformation  preserves  the  holding  of  the 
assertion 

Liveness  Properties 

Generally,  liveness  properties  are  not  specified 
and  proved.  In  some  cases,  the  formal  basis  is  not 
even  in  the  model.  For  example,  in  the  Ina  Jo 
language,  there  is  explicitly  no  requirement  that 
any  transform  (the  transformation  of  the  ND1SM 
is  the  disjunction  of  the  transforms)  be  done.  All 
one  is  allowed  to  show  is  what  will  happen  if  a 
transfc  m  is  done.  Moreover,  at  any  snapshot, 
there  is  no  guarantee  that  any  transform  will  be 
applied.  In  any  case,  even  if  the  necessary  as¬ 
sumptions  are  present,  liveness  properties  require 
existential  quantification  over  snapshots.  This  is 
considered  more  difficult  than  plain  uni-ersal 
quantification  Indeed  if  one  has  only  universal 
quantification  over  snapshots,  one  is  not  obliged 
to  work  with  any  quantification  over  snapshots; 
the  properties  that  hold  on  these  ur.  vcrsally  quan¬ 
tified  snapshots  are  proved  invariant  by  inductive 
means.  In  fact  in  the  cases  of  the  Ina  Jo  language, 
AFFIRM,  and  SPECIAL,  the  accompanying  in¬ 
teractive  or  semi-automatic  proof  system  simply 
cannot  handle  quantification  over  snapshots;  and 
there  is  no  way  to  express  them  in  the  language  of 
the  system. 

Operational  models  can  handle  both  halting  and 
looping  programs.  Unlike  a  functional  treatment 
which  assigns  undefined  to  each  non-halting  com¬ 
putation,  operational  models  consider  the  se¬ 
quence  of  snapshots  in  a  computation  as  the 
meaning  of  any  initial  snapshot.  Hence  non- 
halting  computations  are  distinguishable  by  the 
..idividual  infinite  computation  sequences. 

d.  Formal  Verification  of  Redundantly 
Specified  Properties 

There  are  a  number  of  approaches  to  verifying 
properties  of  NDlSMs.  The  approaches  depend 
on  how  the  F  of  the  NDISM  is  specified,  either 
directly  or  indirectly. 

(i)  For  Directly  Specified  F  of  NDISM 


If  F  is  specified  directly,  the  usual  interests  are 
either  of  the  following 

•  Verify  certain  properties  hold  about  the 
NDISM  specified  by  F,  or 

•  verify  that  an  implementauon  of  the 
NDISM  is  correct. 

If  one  is  to  verify  a  property  of  the  NDISM 
itself,  one  states  the  property  in  the  language  of 
the  NDISM,  say  as  an  assertion  involving  ele¬ 
ments  of  the  snapshot  or  as  a  property  that  F 
must  satisfy  or  a  combination  of  both  Then 
the  assertion  is  proved  by  induction  over  the 
length  of  the  computation. 

If  one  is  to  prove  that  an  implementation  of  the 
NDISM  is  correct,  then  one  must  first  specify 
the  implementation  either  as  another  NDISM 
or  as  a  program  P  implementing  the  compu¬ 
tation  induced  by  F. 

If  the  implementation  of  an  NDISM  Md  is 
given  as  another  NDISM  Mgf  then  the  proof  is 
carried  out  by  showing  that  Mg  simulates  Md 
by  a  proof  technique  (McGowan71,  Berry 72] 
that  is  similar  to  that  used  in  automata  theory 
work. 

One  shows  that  for  each  computation  Cd  in  M  , 
there  exists  a  computauon  Cg  in  Mg  which  be¬ 
haves  the  same  way  By  behaving  the  same 
way  is  meant  that  there  is  a  function  y  lg~>ld 
which  builds  each  snapshot  of  Cd  from  its  cor¬ 
responding  snapshot  in  C  That  y  has  this 
properly  is  shown  by  mathematical  induction 
on  the  length  of  the  computauon  Cd. 

Many  times,  Cg  simulates  Cd  in  a  lock-step 
snapshot-by-snipsbot  fashion.  However,  many 
times,  this  lock-step  simulation  is  not  possible; 
it  takes  several  steps  in  Cg  to  implement  a 
single  step  in  Cd.  The  meaning  of  correspon¬ 
dence  can  be  changed  to  allow  y  to  build  only 
some  of  the  snapshots  of  C,d  out  of  only  some 
of  the  snapshots  of  Cg  The  constraint  is  that  a 
gap  of  no  more  than  some  fixed  number  is  al¬ 
lowed  between  successive  building  snapshots 
in  C  and  between  successive  built  snapshots 
\nCd. 

The  lock-step  situation  is  illustrated  in  Figure 
2.  The  Support  Materials  for  Concepts  of  Con¬ 
current  Programming  has  a  full  formal  defini¬ 
tion  of  simulation  of  one  NDISM  by  another. 


4The  subscript  “d"  signifies  imptementeD,  and  the  subscript  ”g"  signi¬ 
fies  implement  inCi. 
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If  on  the  other  hand,  the  implementation  of  the 
NDISM  is  not  another  NDJSM,  but  is  in  fact 
code  in  some  programming  language,  then  two 
possibilities  exist: 

•  The  whole  NDISM  is  implemented  by  a 
single  program  P.  The  correctness  issue  is 
whether  P  implements  the  whole  of  F  down 
to  the  nondeterministic  choices  and  the  po¬ 
tential  unbounded  computation  length. 

•  The  F  can  be  decomposed  into  a  collection 
of  individual  operations,  each  of  which 
does  one  of  the  possible  transfomiations 
The  operation  of  F  consists,  in  each  appli¬ 
cation,  of  selecting  one  of  these  transfor¬ 
mations  and  executing  only  it.  In  this  case, 
the  usual  implementation  is  built  of  a  col¬ 
lection  of  procedures  for  the  individual 
operations  and  of  a  previously  cooked  shell 
which  chooses  the  right  operation  at  each 
step  and  invokes  the  corresponding  proce¬ 
dure.  The  correctness  issue  is  then  whether 
the  individual  procedures  implement  the  in¬ 
dividual  operations,  the  shell  being 
presumed  correct. 

In  either  case,  one  ends  up  using  the  various 
program  verification  techniques,  such  as  that  of 
Hoare  |Hoare69]  in  which  one  shows  an  actual 
program  to  satisfy  certain  properties 
[Berztiss88], 

( 1 )  NDISM  Implemented  by  Single 
Program 

In  the  first  possibility,  if  the  NDISM  truly 
exhibits  non-deterministic  behavior  and  the 
non-determinism  is  part  of  the  specified  be¬ 
havior,  eg.,  to  specify  concurrency  as  op¬ 
posed  to  possible  allowed  non-concurrent 
computations,  then  the  program  will  have  to 
exhibit  the  same  non-detcrmmism  in  the 
form  of  concurrency.  The  NDISM  specifi¬ 
cation  will  have  to  be  converted  somehow 
into  a  specification  that  is  used  by  one  of  the 
various  methods  to  prove  program  behavior. 
If  the  NDISM  halts  for  all  desirable  com¬ 
putations,  then  input,  output,  and  most  likely 
invariant  assertions  will  have  to  be  gener¬ 
ated  to  describe  the  program’s  behavior.  If 
the  NDISM  intentionally  does  not  halt  for 
all  desirable  compulations,  then  output 
assertions  are  useless,  as  they  vacuously 
hold.  Moreover,  invariant  and  so-called 
"eventually"  assertions,  i.e.,  liveness  asser¬ 
tions,  will  have  to  be  generated  to  describe 
the  program’s  behavior.  Then  the  chosen 
proof  method  is  used  to  verify  that  the  pro¬ 
gram  has  the  desired  behavior.  If  on  the 
other  hand  the  NDISM’s  non-determinism  is 
merely  to  state  allowable  computational  or¬ 
ders,  any  allowed  order  is  considered  cor¬ 


rect,  and  ii  is  nol  required  to  be  able  lo  do 
them  all,  then  standard  methods  for  non- 
concurrent  programs  are  to  be  used  These 
are  outside  the  scope  of  this  module  and  the 
reader  should  consult  [Berzttss88]  for  more 
details 


(2)  NDISM  Implemented  by  a  Collection 
of  Invokable  Procedures 


In  the  second  possibility,  the  problem  hus 
been  reduced  to  showing  *he  correctness  of  a 
collection  of  non-concurrent  subroutines  im¬ 
plementing  non-concurrent  transitions, 
whose  only  non-determinism  is  for  the  pur¬ 
pose  of  allowing  any  one  of  several  possible 
results.  The  concurrency  has  been  pushed 
down  into  the  process  of  selecting  which  of 
the  available  transitions  will  be  invoked 
next.  If  one  verifies  that  the  procedures  do 
implement  the  transitions,  then  to  the  extent 
that  the  basic  invoking  shell  works,  the  col¬ 
lection  of  procedures  plus  the  shell  imple¬ 
ments  the  NDISM  The  meaty  part  of  this 
verification  has  been  reduced  to  the  standard 
non-concurrent  variety  which  is  outside  the 
scope  of  this  module. 


(ii)  For  Indirectly  Specified  F  of  NDISM 


If  F  is  specified  indirectly  with  a  program  P, 
the  interests  are  the  same  as  for  a  directly  spec¬ 
ified  F,  i.e.. 


•  to  verify  that  an  implementation  of  the 
NDISM  is  correct,  or 


•  to  verify  certain  properties  hold  about  the 
NDISM  specified  by  P. 

It  is  rare  that  one  has  to  prove  the  correctness 
of  an  implementation  of  an  NDISM  specified 
by  a  program,  particularly  when  the  specifying 
program  is  executable.  However,  when  it  is 
done,  particularly  when  the  specifying  program 
is  not  executable,  it  is  done  by  proving  the  im¬ 
plementing  and  the  defining  programs  equiv¬ 
alent.  This  proof  can  be  done  by  showing  that 


•  both  compute  the  same  function. 


•  both  satisfy  the  same  formal  specifications, 
albeit  input/output  or  temporal  logical, 

•  a  series  of  correctness  preserving  transfor¬ 
mations  [Baize r81,  Balzer85]  modifies  one 
(usually  the  defining  one)  into  the  other,  or 

•  one  is  compiled  into  the  other. 


Verifying  that  certain  properties  hold  involves 
specifying  these  properties  in  the  fotm  of  asser¬ 
tions  which  are  attached  to  the  program  as  a 
whole  or  to  various  places  in  the  program,  de¬ 
pending  on  the  method  being  used.  Then  the 
code  is  proved  consistent  with  the  assertions  by 
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the  method  being  used.  For  example,  if  one  is 
using  Hoare  logic,  the  assertions  will  be 
sprinkled  around  the  program,  while  if  one  is 
using  temporal  logic,  the  assertions  will  be  at¬ 
tached  to  the  program  as  a  whole.  Assertions 
attached  to  the  program  as  a  whole  describe 
properties  of  the  program’s  computation  as  a 
whole  in  terms  of  particular  snapshots  that  ex¬ 
ist  at  various  times  during  the  computation 
Assertions  attached  to  points  in  the  program 
describe  the  snapshot  at  any  time  execution 
passes  through  that  point. 

e.  Graph  Models  of  Concurrent  Computation 

The  various  graph-based  systems  such  as  control- 
and  data-flow  schemes,  Petri  nets  [Peterson81], 
etc.  are  also  operational.  However,  the  language 
for  expressing  the  parts  of  the  NDISM  is  pictorial. 
Associated  with  each  is  a  description  of  how  a 
diagram  is  to  be  interpreted  as  specifying  a  com¬ 
putation.  Usually  this  description  says  something 
to  the  effect  of 

Select  some  process  node,  all  of  whose  in¬ 
put  arcs  contain  tokens.  Fire  that  node, 
remove  one  token  from  each  input  arc,  and 
deposit  one  token  on  each  output  arc. 

That  description  may  be  stated  in  natural  lan¬ 
guage,  some  programming  language,  some  math¬ 
ematical  language  or  some  mixture  of  all  of  these. 
Generally  what  the  processes  in  the  nodes  do  is 
left  unspecified  or,  to  use  the  terminology,  of  the 
models  uninierpreted.  Those  that  model  data 
flow  as  well  as  control  flow  state  which  data  ob¬ 
jects  are  used,  but  in  the  uninterpreted  domain, 
they  say  nothing  about  the  actual  values  of  the 
data.  Because  there  are  no  interpretations  as  to 
what  the  processes  do,  the  set  of  computations 
that  can  be  described  is  limited.  One  uses  such 
models  strictly  to  focus  on  the  concurrency  and 
synchronization  issues.  The  philosophy  behind 
these  uninterpreted  models  is  that  if  a  property 
can  be  proved  of  an  uninterpreted  model  then  it 
holds  for  all  interpretations  of  that  model.  One 
might  be  able  to  prove  mutual  exclusion  for  a 
program  just  on  the  basts  of  its  control  structures, 
independent  of  any  values  of  any  objects.  Be¬ 
cause  of  the  limited  functionality  in  the  models,  it 
is  generally  easier  to  carry  out  proofs;  there  are 
fewer  operations  to  consider.  On  the  other  hand, 
this  lack  of  functionality  may  prevent  proving 
properties  that  hold  only  because  of  the  values  of 
objects  and  not  strictly  because  of  the  structure  of 
the  programs. 

Because  of  the  limited  functionality,  not  all 
properties  expressible  in  other  operational  models 
are  expressible  in  these  pictorial  models.  For  ex¬ 
ample,  it  is  impossible  to  demonstrate  partial  or 
total  correctness  without  knowing  the  values  of 


objects.  However,  one  can  express  proper  ter¬ 
mination  as  termination,  i  e.,  having  no  fireable 
node  (no  node  has  tokens  on  all  of  its  input  arcs) 
while  having  less  than  some  fixed  number  of 
tokens  on  each  arc.  For  such  control  flow 
schemes,  proper  termination  is  even  decidable 

2.  Axiomatic 

Axiomatic  systems  for  dealing  with  concurrency 
provide  three  main  ingredients, 

1 .  an  assertion  language  for  describing  snapshots 
at  arbitrary  points  in  a  program’s  execution, 
usually  the  language  of  first  order  predicate 
calculus  with  equality, 

2.  a  set  of  axioms  for  describing  the  behavior  of 
primitive  statements, 

3.  rules  of  inference  for  combining  behaviors  of 
constituent  statements  into  behaviors  of  the 
containing  constructs  such  as  loops,  condition¬ 
als,  programs,  etc. 

Hoare  Logic  and  its  Limitations 

Axiomatic  systems  for  dealing  with  concurrency  are 
generally  based  on  Hoare' s  logic  [Hoare69]  or 
Dijkstra’s  weakest  precondition  logic  [Dijkstra76], 
The  main  difficulty  in  using  these  logics  directly  for 
dealing  with  concurrent  programs  is  that  because  of 
the  potential  of  interference,  their  axioms  do  not 
work.  For  example,  the  axiom  for  assignment  is 

{P*e)x-.=e{P) 

which  when  adapted  to  the  assignment  statement 

X : =X+ 1 

under  the  condition  that 
x=l 

prior  to  the  assignment  yields 

{ x=l }  x:=x+l  { x=2 }  . 

However,  as  mentioned  in  Section  II.3.d,  when  this 
assignment  is  executed  in  the  presence  of  other  in¬ 
terfering  processes,  the  value  used  to  compute  x+l 
may  not  be  the  same  as  is  mentioned  in  the  input 
assertion. 

The  various  extensions  to  the  axiomatic  logics  deal 
with  this  interference  problem  in  different  ways. 
The  axiomatic  systems  surveyed  are 

•  the  Owicki-Gries  extension  of  Hoare  logic, 

•  the  Lamport  extension  of  Hoare  logic,  and 

•  the  Lamport  extension  of  Dtjkstra's  weakest 
precondition  logic. 

Owicki-Gries’s  Extension  of  Hoare  Logic 

Owicki  and  Gries  [Owicki76a,  Owicki76b)  use  ordi¬ 
nary  Hoare  logic  axioms  but  put  non-interference 
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requirements  into  the  antecedents  of  rules  of  in¬ 
ference.  For  example,  the  rule  they  give  for  the 
parallel-execution  statement 

resource  r /(variable  list) . rjvar table  list) 

cobegin  Sj  II ...  II  Sn  coend 

is  as  follows. 

If  {PjJSjlCj}  and  ...  {Pn)Sn{Qn}  and  no  variable 
free  in  Pt  or  Qt  is  changed  in  Sj  with  i*j,  and  all 
variables  in  Hr)  belong  to  resource  r,  then 

{/»!  A  •  •  ■  AP„A/(r)l 

resource  r /(variable  list), ... ,  rjvariable  list) 
cobegin  St  II ...  II  Sn  coend 

{01  a  .  .  A0nA/(r)}. 

This  mle  says  that  in  the  case  of  parallel  execution 
of  statements,  the  normal  axioms  and  rules  may  be 
used  for  the  individual  statements  if  there  is  no 
chance  of  interference  between  them.  The  rule  puts 
upon  the  prover  the  obligation  to  show  non¬ 
interference. 

Lamport’s  Extension  of  Hoare  Logic 

Lamport  takes  sort  of  an  opposite  approach,  of 
changing  the  meaning  of  the  assertions  and  the 
axioms  for  primitive  statements  so  that  they  catch 
interference  in  a  slightly  different  way.  In  the  Lam¬ 
port  logic, 

imiei 

means,  "if  execution  is  begun  anywhere  in  S  with 
the  predicate  P  true,  then  executing  S  will  leave  P 
true  while  control  is  inside  S,  and  will  make  Q  true  if 
and  when  S  terminates."  Thus,  Lamport’s  treatment 
of  the  assignment 

X  :  =x+l 

under  the  condition  that 
x=l 

prior  to  the  assignment  is 

{ x=l  A[a/ier('<x+  l>')z>value('<x+ 1  '>)=2] } 
<x>:=<x+l> {x=2j 

In  this,  angle  brackets  are  used  to  surround  opera¬ 
tions  that  are  atomic,  i.e.,  cannot  be  interrupted  and 
are  guaranteed  to  be  done  within  a  single  NDISM 
step  both  in  the  abstraction  and  in  any  implemen¬ 
tation.  The  rule  says  that  if  x  starts  off  as  1,  and 
after  doing  x+1  the  value  of  that  subexpression, 
x+1,  is  still  2,  then  the  assignment  causes  x  to  get  2. 
In  other  words,  if  there  was  no  interference  with  x 
during  the  assignment,  it  behaves  as  an  assignment 
in  the  normal  nonconcurrent  situation.  Of  course,  it 
is  on  the  prover  to  demonstrate  that  there  is  no  inter¬ 
ference.  In  this  sense,  this  approach  is  equivalent  to 
Owicki’s. 


Because  these  axiomatic  methods  prove  that  asser¬ 
tions  which  are  attached  to  specific  places  in  the 
program  are  invariant,  they  really  address  only 
safety  properties. 

Dijkstra’s  Weakest  Precondition  Logic 

Dijkstra  introduced  a  variation  of  die  Hoare 
axiomatic  system  when  he  introduced  a  proof- 
directed  discipline  of  programming  (Dijkstra76).  The 
approach,  that  of  weakest  precondition,  attempts  to 
find  the  weakest  conditions  under  which  a  given 
statement  is  guaranteed  to  halt  and  to  yield  a  snap¬ 
shot  satisfying  a  given  postcondition  For  example, 

H’p(x:=x  +  l,x=2) 


because  only  when  x=l  is  x:=x+l  guaranteed  to 
hall  and  yield  x=2.  The  general  rule  for  the  assign¬ 
ment  statement  is 

wp(  x:=e,  P)  =  P*e, 

the  obvious  correspondent  to  the  Hoare  rule, 
(Pl)x:=e{P). 

There  is  a  dual  for  the  weakest  precondition  called 
the  strongest  postcondition.  The  strongest  postcon¬ 
dition,  sp(S,P ),  of  a  statement  5  and  a  precondition 
P  is  the  strongest  condition  describing  any  snapshot 
yielded  by  the  execution  of  S  from  any  snapshot 
satisfying  P. 

The  Hoare  rule  is  a  partial  correctness  rule,  as  its 
meaning  carries  no  requirement  that  the  statement 
halts.  It  provides  only  that  if  the  statement  halts  then 
the  postcondition  is  true;  if  the  statement  docs  not 
halt,  then  any  postcondition  is  accepted  as  vacuously 
true.  The  weakest  precondition  formulation,  on  the 
other  hand,  finds  preconditions  which  guarantee 
halting  as  well. 

Lamport’s  Extension  of  Weakest  Precondition 
Logic 

Recall  that  most  concurrent  programs  are  systems 
that  are  supposed  never  to  halt.  For  such  programs, 
the  weakest  precondition  would  be  false  for  any 
postcondition.  Therefore,  Lamport  has  developed  a 
variant  of  the  weakest  precondition  approach  that  is 
more  useful  for  concurrent  non-halting  systems.  For 
concurrent  programs  that  do  not  halt,  the  interest 
would  be  to  prove  some  invariant  property,  i.e.,  a 
safety  property.  Accordingly,  Lamport  [Lamport87] 
defines  the  concepts  of  weakest  invariant,  win,  and 
strongest  invariant,  sin,  and  gives  rules  for  deriving 
them  for  programs  given  the  wp,  sp,  win,  and  sin  for 
constituent  statements. 
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/  is  an  invariant  of  S  if 

U)S{I}. 

Lamport  then  defines  S  as  leaving  an  assertion  ! 
invariant  if  and  only  if 

fowp(S,  D ; 

it  is  also  the  case  that 

sp(S,Dz>l . 

Then,  win{S,Q)  is  the  disjunction  of  all  predicates  I 
such  that  I  z>  Q  and  S  leaves  /  invariant,  and 

sin{SyP)  is  the  conjunction  of  all  invariants  /  of  S' 
such  that  P  z>l. 

Lamport  is  able  to  extend  the  Owicki-Gries  method 
to  be  able  to  reason  about  programs  for  which  the 
atomic  operations  are  not  specified.  However,  note 
that  the  weakest  and  strongest  invariants  do  not  give 
the  power  to  work  with  liveness  properties. 

3.  Temporal  Logic 

Temporal  logic  [Pnueli77,  PnueliSl  ]  is  an  attempt  to 
deal  with  the  logic  of  computation  sequences  with¬ 
out  succumbing  to  the  difficulties  of  quantification. 
One  is  able  to  talk  directly  about  sequences  of  snap¬ 
shots,  all  snapshots,  and  the  existence  of  a  snapshot 
that  have  desired  properties.  The  direct  expression 
is  based  on  an  axiomatized  logic  of  time  that  ob¬ 
viates  the  necessity  to  quantify  over  snapshots. 

In  temporal  logic,  one _ is  provided  temporal 

operators,  “henceforth”  ( |  | )  and  “eventually”  (0) 

which  can  be  applied  to  the  standard  assertions 
about  snapshots.  While  they  can  be  defined  relative 
to  each  other  axiomatically,  any  model  of  them 
makes  use  of  some  underlying  NDISM.  Hence,  they 
are  described  here  in  that  manner. 

Basic  Temporal  Operators 

Temporal  semantics  talks  about  assertions  that  hold 
true  in  the  current  snapshot  or  all  or  some  future 
snapshots.  Therefore,  it  will  be  necessary  to  identify 
which  snapshot  in  a  computation  is  the  current  one. 
The  current  snapshot  will  be  called  sc  in  the  follow¬ 
ing  discussions. 

|  |/WVs,(i>CDP(rc)) 


0P=3r((i>CAP(5c)) 

Note  that  occurring  henceforth  includes  occurring  in 
the  current  snapshot.  That  something  eventually  oc¬ 
curs  includes  the  possibility  of  it  occurring  in  the 
current  snapshot. 


Just  as  the  universal  quantifier  and  the  existential 
quantifier  are  duals  of  each  other  so  are  j  |  and  0 


0P.-O 

It  is  useful  to  define  some  other  operators  that  cor¬ 
respond  to  often  used  temporal  relations.  One  such 
useful  relation  is  “leads  to”  ( — >). 

With  these  temporal  operators  it  is  easy  to  express 
both  safety  properties  and  liveness  properties.  To  do 
these,  it  is  necessary  to  let  INIT  be  an  assertion  that 
is  true  at  all  and  only  proper  initial  snapshots;  that 
assertion  is  needed  to  anchor  the  time  to  the  start  of 
the  computation  rather  than  to  any  arbitrary  current 
snapshot. 

Expressing  Properties  with  Temporal  Operators 

Recall  the  general  safety  properties  imrrduCv.d  in 
Section  II.4.a.i. 

•  P  is  true  in  all  snapshots,  i.e.,  /A77bj  |p 

•  P  never  happens,  i.e.,  /A77b|  |~.P 

•  Whenever  P  happens  Q  is  true,  i.e., 

flW7b|  |  (fofl) 

Recall  also  the  general  liveness  properties  intro¬ 
duced  in  Section  II.4.a.ii. 

•  There  exists  a  snapshot  in  which  P  is  true,  i.e., 
INIT^QP 

•  There  exists  a  snapshot  in  which  P  is  not  true, 
i.e.,  INITzo  0  -iP 

•  Whenever  P  happens  then  at  some  later  time  Q  is 

true,  i.e.,  /MTb|  |(P — >Q) 

Temporal  logic  can  even  capture  some  properties 
that  are  neither  safety  nor  liveness,  such  as  the  con¬ 
cept  of  P  happening  infinitely  often. 

/A77b[  [<)P 

Provided  with  the  temporal  logic  is  a  system  of 
axioms  and  rules  of  inference  for  reasoning  directly 
in  the  temporal  domain  without  having  to  fall  back 
on  a  model.  In  order  to  be  able  to  prove  things 
about  a  program  using  temporal  logic  it  is  necessary 
to  provide  a  temporal  logic-based  semantics  of  one's 
programming  language.  Besides  saying  what  each 
kind  of  statement  does,  the  semantics  provides  a  ba¬ 
sic  liveness  property  for  each  primitive  statement 
that  says  that  it  eventually  finishes.  From  this  live¬ 
ness  property  and  the  semantics  of  the  various  con¬ 
structs,  the  prover  is  able  to  prove  liveness 
properties  of  whole  programs. 
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Linear  and  Branching  Time 

There  are,  in  fact,  two  alternative  models  of  time  in 
temporal  logic,  linear  time  and  branching  time. 
Both  are  intended  to  be  used  with  nondeterministic 
computations.  Recall  in  Section  I,  that  two  kinds  of 
nondeterminism  were  identified,  the  kind  that 
models  concurrency  and  the  kind  that  is  used  for 
automata-theoretic  investigations  of  algorithms. 
Linear  time  corresponds  to  the  concurrency- 
modeling  nondeterminism,  and  branching  time  cor¬ 
responds  to  the  automata-theoretic  nondeterminism. 
The  temporal  logic  described  above  is  in  fact  linear 
time,  as  it  was  stated  that 

o 

That  is,  if  it  is  not  true  that  P  never  occurs,  it  even¬ 
tually  occurs.  This  statement  is  true  only  if  there  is 
only  one  possible  future,  namely  a  single  path  down 
the  tree  of  computations.  "Not  occurring  never" 
means  that  it  must  eventually  occur.  However,  in 
branching  time,  automata  theoretic  nondeterminism, 
the  fact  that  it  is  not  true  that  P  never  occurs  means 
that  there  exists  some  computation  in  which  P  does 
occur;  it  may  not  occur  in  all  possible  futures,  i.e., 
all  possible  computations  from  now.  The  formal 
treatment  of  branching  time  is  to  distinguish  be¬ 
tween  the  "eventually"  and  the  "not  never" 
operators.  The  former  has  the  meaning  implied  by 
the  operational  model  and  the  latter  is  the  dual  of  the 
"henceforth”  operator.  However,  since  branching 
time  is  not  really  a  good  model  of  concurrency,  it 
will  be  discussed  no  more  in  this  module. 

Another  Temporal  Operator 

There  is  a  third  temporal  operator  used  by  some  au¬ 
thors,  e.g.,  Ben-Ari,  Manna,  and  Pnueli  [Ben-Ari81] 
and  Hailpem  [Hailpern82],  namely  the  “next”  (o)  op¬ 
erator.  It  applies  its  argument  predicate  to  the  next 
snapshot. 

oP3P(sc+1) 

As  the  use  of  o  implies  an  explicit  time  scale  or  an 
explicit  sequential  progression  of  time,  the  tendency 
is  not  to  use  it.  Using  it  would  overspecify  a  compu¬ 
tation  to  the  point  of  saying  that  a  certain  event  has 
to  happen  in  the  next  snapshot  and  would  not  be 
acceptable  if  it  were  implemented  as  a  multi-step 
procedure. 

Temporal  Logic  Specification  of  Concurrency 

Hailpem’s  Ph  D.  thesis  [Hai!pern82]  defines  a  use¬ 
able  version  of  temporal  logic,  describes  a  program¬ 
ming  language,  VALET,  with  processes  and  moni¬ 
tors,  gives  a  temporal  logic  semantics  for  the  lan¬ 
guage,  and  demonstrates  how  properties  of  programs 
in  this  language  may  be  specified  and  verified. 
These  ideas  are  then  applied  to  specify  and  verify 


the  correctness  of  programs  implementing  a  number 
of  network  protocols  and  resource  allocation  sys¬ 
tems. 

In  VALET,  processes  and  monitors  are  written  in 
the  form  of  separate  modules  that  may  see  and  in¬ 
voke  each  other.  Ihe  form  of  a  process  module  is 
similar  to  that  of  a  Pascal  program.  It  declares  local 
variables  and  has  a  body  consisting  of  a  sequence  of 
statements  which  may  contain  calls  to  procedures 
offered  by  the  monitor  modules  Generally,  the 
body  of  a  process  module  is  an  infinite  loop  A 
monitor  module  declares  local  variables  and  a  col¬ 
lection  of  procedures  invokable  from  outside  the 
monitor,  in  fact,  in  general,  no  module’s  local  vari¬ 
ables  are  visible  from  outside  the  module.  The 
semantics  of  these  modules  is  that  all  process  mod¬ 
ules  are  invoked  to  run  concurrently  at  the  beginning 
of  the  computation.  All  monitors  are  invoked  also  in 
order  to  have  their  initialization  code  executed. 
Then  the  monitors  sit  and  wait  until  monitor  proce¬ 
dures  are  called  by  the  processes.  The  operational 
rule  is  that  no  more  than  one  process  can  be  execut¬ 
ing  the  body  of  any  procedure  inside  a  given  moni¬ 
tor.  The  at  most  one  process  that  is  executing  inside 
a  monitor  procedure  is  said  to  currently  own  the 
monitor. 

For  a  particular  system  involving  process  and  moni¬ 
tor  modules  one  gives  specifications  as  follows  for 
each  module: 

1.  For  each  process,  one  gives  an  invariant  and  a 
commitment. 

2.  For  each  monitor  as  a  whole,  one  gives  an  in¬ 
variant. 

3.  For  each  monitor  procedure,  one  gives  a  ser¬ 
vice  specification  and  a  commitment. 

Invariants 

Among  the  invariants  above,  there  are  two  kinds 
which  are  somewhat  different  from  the  more 
familiar  loop  invariant,  which  is  true  each  time  con¬ 
trol  passes  through  the  loop  cut  point  and  which  may 
not  be  true  at  other  points  in  the  loop.  A  loop  in¬ 
variant  would  be  specified  as  the  following  kind  of 
safety  property: 

\  [(at  Cut  Point  3  !) 

where  /  involves  only  variables  visible  at  the  cut 
point.  The  invariant  of  a  process  is  a  property  of 
variables  visible  to  the  process  which  is  true  at  all 
times.  It  would  be  specified  more  simply: 

o 

where  /  involves  only  variables  visible  to  ihe  proc¬ 
ess.  A  monitor  invariant  is  a  property  of  the  local 
variables  of  the  monitor  which  is  true  at  all  times, 
except  possibly  during  the  execution  of  the  body  of 
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a  monitor  procedure.  This  exception  allows  monitor 
procedure  bodies  to  make  temporary  changes  that 
may  invalidate  the  invariant  so  long  as  they  restore 
the  holding  of  the  invariant  upon  exit.  For  example, 
in  a  monitor  which  keeps  a  linked  list  of  the 
resources  it  is  managing,  the  invariant  would  de¬ 
scribe  a  well-formed  linked  list.  The  monitor  proce¬ 
dure  to  remove  an  item  from  the  list  would  tem¬ 
porarily  invalidate  the  invariant  as  it  performed  the 
pointer  manipulations  to  rebuild  the  list  after  remov¬ 
ing  the  item.  However,  after  the  list  is  rebuilt,  the 
invariant  would  once  again  hold.  It  is  safe  to  let  the 
monitor  procedures  invalidate  the  invariant  tem¬ 
porarily  because  it  is  guaranteed  that  at  most  one 
process  can  be  inside  any  procedure  of  a  monitor  at 
any  given  time.  Therefore,  it  is  not  possible  that  any 
other  process's  concurrent  operation  can  mess  up  the 
list  while  it  is  not  in  proper  form.  It  is  on  the  moni¬ 
tor  writer  to  insure  that  all  invariants  still  hold  when¬ 
ever  a  process  can  relinquish  ownership  of  the  moni¬ 
tor,  namely  upon  a  wait  statement  or  upon  return 
from  a  monitor  procedure.  It  is  this  invariant  that  is 
called  /  in  the  rule  for  the  monitor  procedure  body. 

The  invariant  of  a  process  is  proved  by  standard 
safety  assertion  verification  methods.  That  is,  it  is 
shown  that  the  invariant  holds  upon  initiation  of  the 
process  and  that  each  statement  inside  the  process 
preserves  its  holding.  The  invariant  of  a  monitor  is 
demonstrated  to  hold  after  the  end  of  its  initializa¬ 
tion  part,  and  then  each  monitor  procedure  is  dem¬ 
onstrated  to  preserve  the  invariant’s  holding  across, 
but  possibly  not  within,  its  body. 

Service  Specification 

A  service  specification  for  a  monitor  procedure  is 
simply  its  input/output  specification,  i.e.,  the  P  and 
Q  of  the  rule  for  the  monitor  procedure  body.  This 
is  demonstrated  by  standard  safety  assertion  verifi¬ 
cation  methods. 


monitor  procedure  bodies  are  verified  by  composi¬ 
tion  of  the  liveness  assertions  of  their  constituent 
statements. 

Advantage  of  Temporal  Logic 

The  advantage  of  temporal  logic  in  working  with 
concirrency  is  that  temporal  logic  expressions  read 
more  like  the  natural  language  temporal  statements 
than  do  the  equivalent  snapshot  quantified  asser¬ 
tions.  For  example,  the  temporal  logic  expression 

sentiM)  3  #  0  #(arnve(M)) 

captures  the  natural  language  statement 

“If  a  message  is  sent  then  eventually  it  will  arrive" 

much  more  naturally  than  does 

sentiM, sc)  3  35,(i>  CAarn  ve(Af,s()) 

Certainly,  the  temporal  logic  expression  is  more 
readable  than  is  the  quantified  assertion.  This  more 
natural  flavor  of  the  temporal  logic  allows  it  to  be 
more  abstract  concerning  the  passage  of  time.  Even 
if  the  logic  is  that  of  branching,  discrete  time,  one 
can  write  specifications  that  hide  the  detail  of  dis¬ 
crete  passage  of  time  and  express  that  something 
happens  just  “eventually".  With  quantification  over 
snapshots,  one  must  show  this  aspect  of  the  formal 
model,  even  though  it  is  irrelevant  to  what  is  being 
specified. 

Indeed,  obtaining  this  ability  to  abstract  away  from 
discrete  time  passage  was  the  rationale  behind 
Nixon  and  Wing’s  proposal  to  add  temporal  logic  to 
the  Ina  Jo  specification  language  {Wing89],  The  Ina 
Jo  language  is  for  writing  operational  specifications 
and  in  fact  does  not  permit  quantification  over  snap¬ 
shots.  It  was  proposed  to  add  the  temporal  operators 
by  defining  them  axiomatically  in  terms  of  each 
other  rather  than  by  reducing  them  to  formulae  with 
quantification  over  snapshots. 


Commitment 


A  commitment  is  a  liveness  assertion,  as  it  states 
properties  that  are  guaranteed  to  happen.  Note  that  a 
service  specification  does  not  really  guarantee  very 
much  since  it  is  only  a  statement  of  partial  correct¬ 
ness,  i.e.,  wbat  happens  if  the  body  halts.  A  commit¬ 
ment,  being  a  liveness  assertion  can  carry  a 
guarantee  of  something  happening,  especially  if  it 
contains  an  occurrence  of  the  eventually  operator. 
Indeed,  it  is  for  this  reason  that  processes,  which 
generally  loop  and  do  not  halt,  do  not  have  service 
specifications.  A  process’s  commitment  states  the 
progress  that  it  guarantees  to  have  as  it  loops  in¬ 
definitely. 


The  liveness  assertions  of  a  process  are  proved  by 
composing  the  liveness  assertions  of  its  statements 
and  the  liveness  assertions  of  the  monitor  procedures 
it  calls.  As  mentioned,  liveness  assertions  of  the 


Two  programming  notations  or  program  specifica¬ 
tion  notations  have  been  developed  in  the  temporal 
logic  mold.  One  is  is  a  notation  for  specifying  con¬ 
current  program  modules,  introduced  by  Lamport 
[Lamport83a],  and  the  other  is  UNITY  developed  by 
Chandy  and  Misra  [Chandy88].  Both  use  whatever 
is  convenient  from  mathematics  for  expressing 
values  of  variables.  Both  allow  concurrency  at  the 
level  of  the  assigment  statement.  The  meaning  of  a 
program  is  expressed  in  terms  of  assertions  about 
states  that  hold  at  specific  points  or  globally,  either 
invariantly,  occasionally,  or  at  specific  instances. 
There  are  a  variety  of  temporal  operators  allowing 
expressing  both  safety  and  liveness  properties. 
Lamport’s  description,  being  limited  to  a  journal  ar¬ 
ticle,  is  not  formally  complete.  The  Chandy  and 
Misra  book  gives  full  details  on  the  language  and 
describes  the  meanings  of  statements  and  the  tem¬ 
poral  operatos  axiomatically.  With  the  help  of 
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Boyer-Moore  logic,  the  UNITY  proof  system  has 
been  mechanized  [Goldschlag90a,  Goldschlag90b}. 

Another  language  incorporating  temporal  logic  is 
COL  [Karam91].  COL  is  a  linear-time  temporal- 
logic  based  specification  language,  which  can  be 
used  to  specify  concurrent  Ada  programs  Associ¬ 
ated  with  COL  is  TimeBench,  a  concurrent  system 
design  environment  that  includes  a  deadlock 
analyzer.  TimeBench  is  an  extension  of  the  second 
Buhr’s  CAEDE  visual  Ada  program  design  environ¬ 
ment  and  uses  its  notations  for  expressing  program 
structures. 

4.  Denotational 

There  are  two  main  aspects  to  a  denotational  seman¬ 
tics  of  a  language. 

•  The  semantics  are  described  in  a  syntax-directed 
manner,  that  is  the  meaning  of  a  construct  is  built 
from  only  the  meanings  of  its  direct  syntactic 
components. 

•  The  meaning  of  a  program  is  usually,  but  not 
always,  taken  as  the  function  on  input  to  output 
that  it  computes. 

Actually  the  word  “denotational”  is  used  to  refer  to  a 
definition  which  is  entirely  syntax  directed  as  de¬ 
scribed  above.  In  principle,  any  semantic  domain 
can  be  used,  e  g.,  the  computation  sequence  given 
rise  to  by  an  initial  snapshot.  However,  the  tradition 
is  to  use  the  function  that  a  program  computes  as  its 
meaning.  A  program  which  does  not  halt  at  some 
inputs  is  given  as  its  meaning  a  function  that  com¬ 
putes  undefined  for  those  inputs.  This  tradition  of 
course,  limits  the  applicability  of  denotational 
semantics  to  function  programs.  T  his  particular  kind 
of  denotational  semantics  would  not  be  useful  for 
modeling  looping  programs  such  as  operaung  sys¬ 
tems. 

Nonconcurrent  Flow  of  Control 

In  order  to  be  able  to  model  gotos  and  other  wild 
flows  of  control  without  needing  other  than  direct 
syntactic  components,  the  semantics  of  each  lan¬ 
guage  feature  is  given  as  a  function  of  itself,  tlie 
current  snapshot  information,  and  a  continuation. 
The  continuation  of  a  construct  is  the  function  com¬ 
puted  by  the  part  of  the  computation  that  follows  the 
completion  of  the  construct,  i.e.,  the  rest  of  the  com¬ 
putation. 

This  continuation  turns  out  to  be  the  value  of  a  label, 
so  that  doing  a  goto  means  replacing  the  continua¬ 
tion  that  exists  at  the  point  of  the  goto  by  the  one 
which  is  the  value  of  the  label. 

Concurrency  and  Processes 

The  facts  that  processes  do  gotos  and  labels  arc  con¬ 
tinuations  leads  directly  to  the  conclusion  that  a 


process  should  also  be  a  continuation  However, 
here  what  function  is  computed  by  this  continuation 
is  not  clear  The  normal  continuation  computes  the 
final  snapshot,  if  it  exists,  as  a  function  of  the  cur¬ 
rent  snapshot  and  the  changes  caused  by  the  current 
statment.  Thus,  the  continuation  corresponding  to  a 
process  should  compute  all  possible  final  snapshots 
as  a  function 

•  of  the  current  snapshot, 

•  which  of  (lie  processes  is  selected  to  execute 
next,  and 

•  the  changes  that  the  selected  process's  next  state¬ 
ment  causes 

In  normal  denotational  semantics,  continuations  are 
composed  to  build  other  continuations  That  is,  the 
continuation  from  now  until  the  end  of  the  current 
loop  is  composed  with  the  continuation  from  the  end 
of  the  loop  until  the  end  of  the  computation  to  get 
the  continuation  from  now  until  the  end  of  the  com¬ 
putation.  Recalling  the  tree  of  Figure  1,  consider 
how  this  composition  would  occur.  In  Figure  3,  the 
left  hand  contour  delimits  the  part  of  the  tree  denot¬ 
ing  one  continuation,  say  to  the  end  of  the  current 
cobegin-coend  construct.  The  right  hand  contour 
denotes  the  continuation  going  from  the  end  of  the 
cobegin-coend  construct  to  the  end  of  the  compu¬ 
lation.  Their  composition  is  not  the  whole  tree. 
Figure  4  shows  a  computation  tree  with  no  forks;  in 
such  a  deterministic  case,  the  composition  of  the  two 
parts  of  the  path  is  the  whole  computation,  as  is 
desired.  The  reason  for  this  is  that  in  composing  one 
choice's  continuation  with  the  continuation  contain¬ 
ing  the  choice,  one  loses  the  ability  to  choose  the 
unchoscn  choices.  Thus,  concurrent  continuations 
cannot  be  usefully  composed.  Other  means  must  be 
found  to  build  continuations.  See  the  literature 
[Plotkin76,  Smyth78,  Berry85,  Scbmidt86]  for  more 
details. 

Limited  Concurrency 

The  result  of  these  difficulties  is  that  most  denota- 
lional  semantics  of  concurrency  have  focussed  on 
non-shared  memory  concurrency  in  which  tire  only 
interaction  between  processes  is  via  messages  sent 
along  a  communication  channel  that  enforces 
synchronized  access  [FrancezSO).  The  restricted  in¬ 
teraction  greatly  limits  the  number  of  choices  that 
have  to  be  re-interleaved.  Indeed,  if  two  processes 
are  totally  non-interfering  there  is  no  need  to  inter¬ 
leave  them.  [Plotkin76,  Plotkin83] 

5.  Comparisons  of  the  Coverage  of  the 
Approaches 

The  view  of  the  world  is  three  dimensional,  and  the 
dimensions  are 

1 .  the  nature  of  the  program, 

2.  the  nature  of  the  property  to  ''"3 
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3.  the  definitional  and  proof  approach. 

The  choices  for  each  dimension  are: 

1 .  the  nature  of  the  program: 

•  functional,  i.e.,  halting 

•  looping 

2.  the  nature  of  the  property  to  prove: 

•  safety 

•  liveness 

3.  the  definitional  and  proof  approach: 

•  axiomatic 

•  denotations! 

•  operational 

•  temporal 

The  Issue  is,  “For  any  configuration  of  two  dimen¬ 
sions,  which  choices  of  the  third  are  available.” 
Since  three  dimensional  paper  does  not  exist  yet,  it 
is  necessary  to  show  the  world  as  three  two- 
dimensional  tables,  as  Figure  5  shows. 

The  first  of  these  shows  all  the  approaches  that  can 
be  used  for  any  given  property  that  is  to  be  proved 
about  any  kind  of  program.  The  choices  are  more 
limited  for  liveness  properties  and  for  looping  pro¬ 
grams.  Liveness  properties  cannot  be  handled  by 
strictly  inductive  invariance  proofs,  and  looping  pro¬ 
gram:  :ausc  partial  correctness  and  functional  ap¬ 
proaches  to  be  to  give  no  useful  information.  The 
functional  approaches  are  those  that  try  to  treat  all 
programs  as  implementing  functions,  i.e.,  the 
axiomatic  and  the  denotational  approaches. 

The  second  table  shows  all  the  properties  that  can  be 
proved  for  any  kind  of  program  using  any  of  the 
discussed  approaches.  This  table  shows  that  the 
functional  approaches  cannot  be  used  with  looping 
programs  to  prove  any  useful  properties.  It  is  clear 
that  safety  is  more  universally  covered  than  is  live¬ 
ness. 

Finally,  the  third  table  shows  all  the  kinds  of  pro¬ 
grams  for  which  one  can  prove  the  various 
properties  using  the  various  approaches.  In  this 
table,  it  is  clear  that  it  is  much  harder  to  deal  with 
looping  programs  than  functional  programs,  and  that 
axiomatic  approaches  do  not  help  at  all  when  trying 
to  prove  liveness. 

The  following  summarizes  what  is  possible  for  the 
approaches. 

•  Operational  models  can  deal  with  either  func¬ 
tional  or  looping  programs  and  are  always  useful 
for  demonstrating  safety  properties.  They  may 
be  used  to  demonstrate  liveness  properties  only 
if  the  language  permits  quantification  over  snap¬ 
shots;  most  do  not. 

•  Axiomatic  models  based  on  partial  correctness 
deal  only  with  functional  programs,  and  since 


they  work  with  invariants,  they  are  useful  only 
for  demonstrating  safety  properties 

•  Temporal  semantics,  not  being  tied  to  partial  cor¬ 
rectness,  can  deal  with  either  functional  or  loop¬ 
ing  programs  and  are  useful  for  demonstrating 
safety  and  liveness  properties 

•  Denotational  semantics,  as  traditionally  used, 
can  deal  only  with  functional  programs  and  are 
useful  for  demonstrating  safety  and  liveness 
properties  but  only  of  processes  that  do  not  share 
memory.  When  processes  share  memory,  the 
amount  of  interaction  possible,  and  which  must 
be  dealt  with  formally,  explodes  to  the  point  of 
intractability. 

IV.  Actual  Specifications  of  Software 

In  the  literature,  a  number  of  the  above  formal  systems 
have  been  used  to  specify  concurrent  programs  and  in 
some  cases,  properties  have  been  proved  of  them.  The 
primary  examples  have  been  in  verifying  security  of 
operating  system  kernels,  verifying  integrity  of  data¬ 
bases,  and  verifying  the  correctness  of  protocols. 

1.  Operating  System  Security 

The  approach  taken  by  the  various  workers  in  the 
security  area  is  an  operational  one.  The  main  prob¬ 
lem  is  to  design  an  operating  system  that  enforces  a 
certain  security  policy.  It  is  recognized  that  to  prove 
an  entire  operating  system  adhering  to  any  but  the 
most  trivial  property,  e.g.,  true,  is  hopeless  because 
of  the  sheer  size  of  the  code  for  an  operating  system. 
Fortunately,  for  a  security  policy,  it  is  not  necessary 
prove  that  the  entire  operating  system  enforces  it. 
M.'Sl  operating  systems  are  structured  in  such  a 
manner  that  a  small  kernel  gets  the  job  of  allocating 
objects  to  users  and  enforcing  the  policy.  If  the 
kernel  properly  does  its  job  and  the  only  way  the  rest 
of  the  system  and  any  other  program  or  procedure 
can  get  to  the  protected  objects  is  by  invoking  the 
kernel  operations,  then  it  is  not  necessary  to  worry 
about  what  the  rest  of  the  system  or  the  other  pro¬ 
grams  or  procedures  do.  Thus,  in  a  properly  struc¬ 
tured  kernel-based  operating  system,  it  suffices  to 
verify  that  the  kernel  does  the  job  right  and  to  ar¬ 
range  that  the  rest  of  the  system  and  no  other  pro¬ 
gram  or  procedure  can  directly  access  the  protected 
objects.  The  latter  can  usually  be  verified  by  inspec¬ 
tion  that  no  objects  are  accessed  directly  or  it  can  be 
enforced  by  the  compiler's  normal  symbol  table 
mechanism;  that  is,  the  protected  objects  are  not 
even  visible  in  the  symbol  table.  Thus,  the  problem 
of  verifying  the  security  of  a  kernel-based  system  is 
reduced  to  that  of  verifying  the  security  of  the  kernel 
itself. 

It  has  been  said  that  the  only  programs  that  can  be 
verified  are  toy  programs.  The  kernel-based  ap¬ 
proach  [Popek75,  Popek79|  aims  to  make  the  only 
program  that  has  to  be  verified,  i.e.,  the  kernel,  small 
enough  to  be  a  toy! 
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Security  Policy  Identification 

In  the  typical  effort  to  design  and  implement  a 
verifiably  secure  operating  system,  the  effort  begins 
with  an  identification  of  the  security  policy 
[Landwehr  81,  LandwehrSJj,  that  is,  what  objects  are 
going  to  be  protected,  what  is  the  nature  of  this  pro¬ 
tection,  and  from  whom  they  are  going  to  be 
protected  The  usual  situation  is  that  files  are  the 
objects  being  protected  and  they  are  being  protected 
against  inappropriate  access  by  processes  represent¬ 
ing  users.  For  example,  a  file  may  be  given  a  classi¬ 
fication,  e.g.,  secret  or  top  secret,  based  on  the  sensi¬ 
tivity  of  its  contents.  That  file  would  be  protected 
from  being  read  by  processes  representing  users 
whose  clearance  is  not  at  least  equivalent  to  the  clas¬ 
sification  of  the  file,  i.e.,  secret  or  top  secret,  respec¬ 
tively.  The  system  might  also  allow  blind  append¬ 
ing  of  this  file  by  any  process  whose  clearance  is  at 
least  equivalent  to  the  classification  of  the  file.  The 
formalized  security  policy  most  often  quoted  is  that 
of  Bell  and  LaPadula  [Bell73], 

Decomposition  of  System 

Once  the  elements  of  the  policy  are  identified,  it  is 
necessary  to  decompose  the  system  into  two  parts, 
the  kernel  and  the  rest.  The  intention  is  that  the 
kernel  will  be  concerned  with  at  least  everything  that 
can  affect  or  be  affected  by  the  security  policy,  i.e., 
the  files,  the  processes,  and  the  access  rights  and  the 
operations  governed  by  these  rights.  The  kernel  is 
designed  so  that,  in  the  case  of  the  example,  the  only 
way  to  create  processes  and  files  is  by  asking  the 
kernel  to  do  so  and  the  only  way  that  processes  can 
gain  access  to  files  for  reading  and  writing  is  by 
asking  the  kernel  for  permission  to  do  so,  and  the 
only  way  that  processes  can  actually  read  from  or 
write  to  files  is  by  having  obtained  permission  from 
the  kernel.  This  means  that  in  the  rest  of  the  system 
and  in  any  other  program  running  on  the  system, 
these  operations  on  files  and  processes  can  be  done 
only  by  invoking  kernel  routines  or  by  invoking 
routines  that  ultimately  invoke  kernel  routines. 

This  particular  decomposition  of  a  system  into  a  ker¬ 
nel  and  the  rest  makes  sense  from  the  software  engi¬ 
neering  point  of  view.  A  glance  at  the  way  operat¬ 
ing  systems  are  designed,  not  for  the  purpose  of  en¬ 
forcing  security,  but  for  the  purpose  of  making  an 
easy  to  understand  and  easy  to  maintain  system, 
shows  the  same  basic  decomposition  being  followed 
[Dijkstra68,  Organick72,  Ritchie74,  Comer84, 
Bach86,  Tanenbaum87], 

Specification  of  Policy 

The  specification  of  the  kernel  includes  a  specifi¬ 
cation  of  security  policy  that  it  must  satisfy.  The 
usual  approach  is  to  specify  an  NDISM  in  which  F 
is  a  function  that  non-deterministically  invokes  ker¬ 
nel  operations.  That  is,  at  each  transition  some  one 


kernel  operation  is  selected  for  execution  The 
security  policy  is  expressed  as  an  invariant  and  other 
assertions  that  the  operations  must  preserve  and  sat¬ 
isfy.  For  example,  that  in  all  snapshots  no  process 
has  read  access  to  any  file  that  is  at  a  classification 
higher  than  its  clearance  is  an  invariant  expressing 
pan  of  the  example  policy. 


This  particular  formal  model  has  two  important 
simplifying  assumptions. 

1.  The  model  does  not  necessarily  insist  that  the 
only  thing  that  can  happen  during  a  compu¬ 
tation  is  what  is  specified.  Thus,  the  model 
assumes  that  any  thing  else  that  might  happen 
is  simply  not  security  relevant.  This  is  reason¬ 
able  if  it  is  known  that  ail  accesses  to  the  en¬ 
tities  involved  in  the  security  policy  are  de¬ 
scribed  completely  in  the  model 
[Kemmerer82]. 

2.  The  execution  of  each  kernel  operation  is  indi¬ 
visible,  so  that  it  is  a  correct  model  to  inter¬ 
leave  at  the  level  of  their  invocation.  This  is 
reasonable  since  in  most  systems,  such  opera¬ 
tions  are  implemented  in  a  non-interruptible 
manner  so  that  they  are  effectively  indivisible. 


Iterative  Design  Process 


The  designers  begin  an  iterative  process  which  halts 
only  when  the  operations  as  specified  provably  meet 
the  security  requirements  as  specified.  They  attempt 
to  prove  the  operations  as  specified  meet  the  speci¬ 
fied  requirements.  Each  failure  to  do  so  leads  to 
closer  inspection  of  both  the  operation  specifications 
and  the  security  policy  specifications.  Usually  this 
examination  leads  to  identification  of  the  reason  that 
the  proof  fails,  and  this  identification  leads  to 
changes  to  the  operations,  their  specifications,  the 
security  policy,  and  its  specification.  After  changes 
are  made,  a  proof  is  again  attempted.  It  is  probably 
this  close  inspection  and  subsequent  changes  that  are 
the  most  valuable  aspects  of  the  method,  far  more 
valuable  than  the  proof  per  se. 


Program  Development 

Once  the  kernel  specification  has  been  verified  to 
adhere  to  the  desired  security  policy,  two  particular 
program  developments  may  proceed.  One  of  these 
is  of  the  software  that  uses  the  kernel.  The  two  main 
constraints  on  any  such  software  are  that 

1.  it  invoke  only  kernel  operations  when  it 
wishes  to  do  something  which  can  be  security 
relevant  and 

2.  these  invocations  assume  the  specifications 
given  in  the  NDISM  for  the  kernel. 


The  other  program  development  is  that  of  the  kernel 
itself.  Assuming  that  the  kernel  is  structured  as  a 
collection  of  subroutines  that  can  be  invoked  from 
outside  the  kernel,  i.e.,  a  collection  of  supervisor 
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routines,  it  suffices  to  show  that  each  subroutine  cor¬ 
rectly  implements  its  corresponding  transition  speci¬ 
fication,  The  specification  of  each  such  transition 
tends  either  to  be  deterministic  or  non-deterministic 
with  the  intent  of  specifying  allowed  variations  and 
not  concurrency.  Therefore  proving  these  sub¬ 
routines  correct  can  be  done  with  traditional  non- 
concurrent  methods,  as  covered  in  [Berztiss88].  The 
important  thing  here  is  the  concept  that  if  the  speci¬ 
fication  of  an  operation  meets  a  given  requirement 
and  one  has  shown  that  a  procedure  correctly  imple¬ 
ments  the  specification,  then  one  has  also  shown  that 
the  procedure  meets  the  given  requirement. 

A  fuller  description  of  the  technique  is  given  in 
[Cheheyl81],  This  paper  describes  the  general  tech¬ 
nique  and  four  different  specification  languages.  A 
small  example  illustrates  each  one. 

The  famous  Orange  book  [Klein83]  describes  re¬ 
quirements  for  systems  to  be  accepted  as  secure  by 
the  Department  of  Defense.  It  specifies  both  the 
basic  policy  that  must  be  implemented  and  the 
methods  by  which  the  system  must  be  developed  and 
verified  to  implement  the  policy.  A  system  cannot 
receive  so-called  Orange-book  certification  unless  it 
was  developed  and  verified  in  a  manner  that  inspires 
confidence  in  the  claimed  security.  In  other  words, 
how  the  system  is  designed  and  implemented  is  at 
least  as  important,  if  not  more,  than  what  policy  it 
implements  —  a  recognition  of  the  importance  of 
having  a  systematic  method  for  engineering  the 
secure  system.  One  system  that  has  been  certified 
A1  Secure  under  the  Orange  book  is  SCOMP 
[Benzel84], 

Real-Life  Use  of  t  echnique 

The  method  has  been  applied  a  number  of  times  at 
the  level  of  verifying  that  the  specified  NDISM 
meets  the  security  requirements.  To  this  author's 
knowledge,  the  method  has  never  been  carried  out  to 
the  point  that  the  implementation  meets  the  security 
requirements.  While  this  failure  is  an  indictment  of 
claims  to  practicality  of  formal  proof  methods,  in 
practice  the  failure  is  not  that  serious.  It  is  generally 
agreed  that  the  hard  part  of  the  implementation  of  a 
secure  system  is  getting  the  specification  of  the  ker¬ 
nel  right.  The  kernel  procedures  are  small  enough 
and  generally  simple  enough  that  getting  their  im¬ 
plementations  right  is  far  easier. 

Limitation; 

The  method  has  its  limitations. 

•  The  system  can  be  no  securer  than  the  specifi¬ 
cation  of  security.  That  is,  if  the  desired  concept 
of  security  is  not  covered  by  the  specification, 
then  the  system  may  not  satisfy  it,  and  it  cannot 
be  expected  to  observe  it.  For  example,  the 
specified  security  policy  may  state  that  a  process 


cannot  get  read  access  to  files  with  a  classifi¬ 
cation  higher  than  its  clearance.  However,  prov¬ 
ing  this  will  not  prevent  a  process  from  reading 
snapshot  changes  caused  by  another  process  that 
can  legitimately  read  the  file.  If  that  process 
purposefully  changes  snapshot  at  an  agreed  upon 
rate  so  as  to  signal  the  bits  of  the  content  of  the 
file  it  can  read,  then  it  will  manage  to  transmit 
the  contents  of  the  file  to  other  processes  that  are 
not  supposed  to  have  access  to  the  file 

•  Because  of  the  sheer  difficulty  of  carrying  out 
proofs,  what  is  specified  tends  to  be  only  the 
barest  minimum  of  security  relevant  properties. 
No  attempt  is  made  to  prove  that  the  transitions 
do  what  they  are  supposed  to.  There  is  no 
guarantee  that  an  operation  to  read  a  file  in  fact 
causes  copying  of  the  contents  of  that  file,  only 
that  the  copying  does  not  happen  unless  the 
security  policy  permits  it.  In  some  cases,  the 
formal  system  used  cannot  even  guarantee  that 
an  operation  once  invoked  will  even  terminate. 
The  formal  system  handles  only  safety  properties 
and  not  progress  properties.  Note  that  an  opera¬ 
tion  that  does  not  give  die  data  that  is  requested 
is  quite  secure,  but  it  is  not  very  useful. 

•  The  security  is  as  good  as  the  underlying  as¬ 
sumptions  of  correctly  performing  compilers, 
hardware,  etc.  The  software  has  still  kept  its 
promise  if  as  a  result  of  a  hardware  failure,  all 
top  secret  files  get  spilled  out  to  the  line  printer 
that  is  in  a  public  reading  room. 

Network  Security 

Several  authors  have  dealt  witht  the  related  problem 
of  secure  transmission  of  messages  over  a  non- 
secure  network,  i.e.,  of  making  sure  that  the  intended 
recipient  and  only  the  intended  recipient  of  a  mes¬ 
sage  see  the  message  [Good82,  Britton84], 

2.  Database  Integrity 

Given  a  database  scheme,  consisting  of  a  collection 
of  data  types,  e.g.,  for  relations  or  inverted  trees, 
etc.,  operations  that  can  be  performed  on  the  data, 
and  a  statement  of  what  it  means  for  the  data  to  have 
integrity,  the  problem  is  to  insure  that  the  database 
will  maintain  that  integrity 

Run-Time  Checking 

The  more  usual  situation  is  to  do  the  checking  at  run 
time.  However,  this  is  expensive.  Moreover,  it  is 
not  clear  what  to  do  if  the  data  are  discovered  not  to 
have  integrity;  the  operation  that  made  the  change, 
which  is  the  primary  cause  of  the  lack  of  integrity, 
may  have  been  done  long  ago. 

Verification  Approach 

Another  approach  is  to  verify,  at  design  time,  that 
the  database  as  specified  has  the  required  integrity. 
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This  approach  to  database  integrity  verification  is  an 
operational  one  which  is  similar  to  that  of  operating 
system  kernel  security  verification.  One  defines  an 
ND1SM  to  model  the  database;  /  defines  the  scheme, 
/0  defines  the  initial  configuration,  F  defines  the 
operations.  The  integrity  constraints  are  then  ex¬ 
pressed  as  an  assertion  on  /.  To  prove  that  the  data¬ 
base  has  in'egrity,  it  suffices  to  show  that  the  in¬ 
tegrity  constraints  assertion  is  an  invariant.  That  is 
the  integrity  constraint  folds  for  all  elements  of  /0 
and  it  is  preserved  by  each  operation  [Leveson83], 
jPaolini81  j. 

Once  the  NDiSM  definition  of  the  database  has  been 
verified  to  have  integrity,  any  correct  implementa¬ 
tion  of  it  also  has  integrity.  Furthermore,  any  data¬ 
base  application  programmed  entirely  in  terms  of 
operations  of  the  NDISM  is  also  guaranteed  to  have 
integrity;  this  is  because  all  accesses  to  the  dai  ibase 
are  through  operations  that  are  guaranteed  to  pre¬ 
serve  integrity. 

The  upshot  of  this  approach  is  that  no  additional 
run-time  integrity  checks  are  needed.  It  is  known 
that  the  operations  are  designed  never  to  get  the  data 
into  a  snapshot  in  which  they  do  not  satisfy  the  in¬ 
tegrity  constraints. 

Limitations 

The  method  suffers  from  the  same  drawbacks  as 
does  verifying  security,  e.g,  the  real  integrity  of  the 
database  is  only  as  good  as  the  specification  of  what 
integrity  means.  If  the  database  is  a  concurrent  one, 
i.e.,  several  processes  may  be  accessing  the  data  at  a 
time,  then  the  same  approach  works.  All  that  is 
required,  as  is  the  case  with  operating  system  ker¬ 
nels,  is  that  the  operations  be  indivisible  or  atomic. 

Making  Operations  Atomic 

There  are  a  number  of  approaches  to  making  the 
implementation  of  the  operations  atomic.  The  brute 
force  method  is  to  physically  prevent  more  than  one 
process  at  a  time  from  accessing  the  database.  This 
approach  is  wasteful,  however.  In  a  truly  large  data¬ 
base,  it  is  quite  likely  that  the  concurrent  accesses 
are  to  independent  parts  of  the  database.  In  such  a 
case,  concurrent  access  is  not  harmful,  and  disallow¬ 
ing  it  would  slow  down  the  operation  of  the  database 
intolerably;  Consider  an  airline  reservation  system  in 
which  only  one  agent  world-wide  could  access  the 
database  at  a  time.  A  more  useful  approach  is  to  use 
a  two-phase  commit  [Bernsteifi87]  in  which  a  proc¬ 
ess  does  all  the  calculations  necessary  to  do  an  up¬ 
date  unprotected,  but  then  just  before  it  is  about  to 
write  the  changes,  it  grabs  uninterruptible,  unique 
access  to  the  data,  checks  that  all  data  that  con¬ 
tributed  to  the  new  values  have  not  changed,  and  if 
not,  then  writes  the  changes  and  releases  access  to 
the  data.  If  the  process  finds  that  at  least  one  con¬ 


tributing  datum  has  changed,  the  process  releases 
access  and  backs  out  of  the  operation.  If  the  fre¬ 
quency  of  concurrent  access  is  low  enough,  then  the 
probability  is  high  that  the  process  will  be  able  to 
write  the  changes.  With  the  right  frequency  of  con¬ 
current  access,  the  two-phase  commit  exhibits  sig¬ 
nificantly  more  throughput  than  using  the  brute- 
force  method. 

3.  Protocols 

Network  protocols  are  generally  modeled  as  proc¬ 
esses  passing  messages  to  each  other  across  some 
bi-directional  media.  The  medium  between  two 
processes  is  modeled  as  storage  accessible  to  both 
processes  that  holds  die  transmitted  message  for  at 
least  one  snapshot.  If  the  protocol  is  designed  to 
work  across  faulty  media,  then  in  the  formal  model 
the  storage  is  given  the  ability  to  generate  spurious 
data,  to  lose  data,  and  to  corrupt  data  with  nonzero 
probabilities.  The  procedure  that  the  processes  ex¬ 
ecute  in  order  to  send  and  receive  messages  is  called 
the  protocol.  Generally,  all  processes  execute  the 
same  protocol  procedure,  and  the  procedure  tends  to 
have  a  part  that  deals  with  sending  and  a  part  that 
deals  with  receiving.  The  two  parts  may  even  be 
two  different  invokable  procedures.  Usually,  in  an 
attempt  to  simplify  the  formal  model  while  retaining 
its  focus  on  the  protocol,  the  formal  model  consists 
only  of  two  processes,  a  sender  executing  only  the 
sending  pan  and  the  receiver  executing  only  the 
receiving  pan  of  the  protocol,  and  a  uni-directional 
medium. 

Main  Properties  to  Prove 

The  main  property  that  it  is  generally  desired  to 
prove  about  a  protocol  is  that  if  a  message  m  is  sent 
from  the  sender,  it  eventually  is  received  uncor- 
rupted  by  the  receiver.  For  some  protocols,  there 
may  be  additional  properties,  such  as  that  the  mes¬ 
sages  arrive  uncorrupted  in  the  order  that  they  are 
sent. 

The  second  of  these  properties  is  a  safety  property, 
because  it  says  that  in  all  snapshots,  the  sequence  of 
messages  sent  by  the  sender  is  an  initial  subsequence 
of  the  sequence  of  messages  received  by  the 
receiver.  However,  the  main  property  is  a  Iiveness 
property,  because  it  says  that  in  all  snapshots,  if  a 
message  is  sent  by  the  sender  in  that  snapshot,  then 
there  exists  a  later  snapshot  in  which  the  same  mes¬ 
sage  has  been  received  by  the  receiver.  Hence,  a 
popular  way  to  specify  and  verify  properties  of 
protocols  is  with  temporal  logic  [Hai!pern82, 
SchwartzSI,  Lamport83a,  Schwabe85,  Wolper82, 
Nguyen84], 

Temporal  Logic  Specifications 

As  an  example,  consider  a  general  protocol  specifi¬ 
cation  given  by  Hailpem.  In  this  specification,  the 
medium  is  modeled  as  a  monitor: 


20 


SEI-CM-27-1.0 


Formal  Specification  and  Verification  of  Concurrent  Programs 


send(m): 
pre:  ct =A 
post:  a=Aon> 
live:  0  (after  send) 

receive(var  m): 
pre:  (3=B 
post:  p=fl<;n> 

live:  0  ( ExistsM )  z>  (after  receive) 

ExistsM: 
pre:  true 
post:  true 

live:  Q  (after  ExistsM) 

Monitor  Invariant: 

ExistsM  a|  [(-lafter  receive)  o|  [(ExisrsAf) 

Note  how  a  message  cannot  be  received  until  after 
the  message  exists  in  the  communication  medium. 
The  monitor  invariant,  relying  on  the  assumption  of 
only  one  receiver,  says  that  if  ExistsM  becomes  true, 
then  it  will  not  become  false  before  a  receive  opera¬ 
tion  takes  place,  i.e.,  if  an  existing  message  is  never 
received  then  it  will  always  be  existing. 

The  property  that  the  medium  can  duplicate,  lose, 
and  re-order  messages  is  captured  by  using  history 
variables  a  and  |J  which  keep  the  list  of  messages 
sent  and  received  respectively.  Then  it  is  specified 
that 


meaz>me$ 

Thus  no  spurious  and  corrupted  messages  are  cre¬ 
ated.  In  order  that  the  protocol  eventually  deliver  a 
message,  it  must  be  that  Lire  medium  eventually 
transmits  a  message  if  it  is  sent  often  enough.  This 
is  guaranteed  by  putting  two  commitments  on  the 
medium,  one  for  the  send  end  and  one  for  the 
receive  end. 

agrows-without-bound  d|  j()  ( ExistsM) 

m  repeated-wiihoul-bound~in  a 
a(J  grows-without-bound 
z>()(me$) 

The  first  says  that  pumping  enough  messages  into 
the  medium  guarantees  that  eventually  one  will  exist 
in  the  medium.  The  second  says  that  if  a  particular 
message  is  pumped  into  the  medium  often  enough 
and  the  receiver  receives  often  enough,  then  even¬ 
tually  the  particular  message  will  be  received. 

Hailpem's  book  describes  two  other  protocols  in  de¬ 
tail  and  proves  that  each  causes  its  medium  to  satisfy 
the  service  specification  and  the  commitment  of  the 
medium  described  above. 


Operational  Specifications 

There  are  a  number  of  operational  definitions  of 
protocols.  Among  them  are  specifications  written  in 
AFFIRM  [Sunshine82]  and  in  a  graphic  specifica¬ 
tion  language  invented  by  Chen  and  Yeh  [Chen83], 

AFFIRM 

The  AFFIRM  language  has  been  used  to  specify  a 
variety  of  protocols  and  the  AFFIRM  verification 
environment  has  been  used  to  verify  a  number  of 
properties  of  these  specifications.  A  later  section 
describes  AFFIRM  and  its  environment.  For  now,  it 
suffices  to  say  that  AFFIRM  allows  specifications  of 
NDISM  in  a  way  in  which  it  is  possible  to  quantify 
over  snapshots.  Therefore,  it  is  possible  in  AFFIRM 
to  specify  liveness  as  well  as  safety  properties.  Sun¬ 
shine,  Thompson,  Erickson,  Gerhart,  and  Schwabe 
[Sunshine82]  have  written  a  paper  in  which  they 
show  bow  several  protocols  can  be  specified  and 
verified  to  satisfy  a  number  of  useful  properties. 

They  define  a  basic  service  protocol  which  captures 
what  the  protocol  user  sees,  that  is,  as  a  reliable 
medium  which  delivers  all  messages,  uncorrupted, 
and  in  the  order  sent.  Typical  of  the  properties  of 
the  service  protocol  that  they  specify  are: 

•  Messages  are  delivered  uncoirupted  and  in  the 
order  sent,  a  safety  property. 

•  All  messages  that  are  sent  are  delivered,  a  live¬ 
ness  property. 

These  are  specified  using  whatever  needed  quan¬ 
tification  over  snapshots.  Then  the  AFFIRM  natural 
deduction  interactive  verifier  is  used  to  prove  that 
the  service  protocol  satisfies  these  properties  Ac¬ 
tually,  failed  attempts  to  prove  these  properties  of 
the  service  protocol  led  to  modifications  to  the  spec¬ 
ifications  of  both  the  service  protocol  and  the 
properties.  These  modifications  continue  until  the 
proofs  had  been  successfully  carried  out. 

Then  they  define  a  number  of  implementing 
protocols,  sucb  as  the  Alternating  Bit  (AB)  protocol, 
whose  job  is  to  implement  the  service  protocol  given 
unreliable  transmission  media  that  lose  messages, 
corrupt  messages,  generate  noise,  etc.  They  prove 
that  the  implementing  protocol  satisfies  the 
properties  of  the  service  protocol  by  proving  each  of 
the  service  properties  as  theorems  in  the  implement¬ 
ing  protocol  under  the  mapping  from  the  implement¬ 
ing  protocol  data  to  the  service  protocol  data.  Inter¬ 
estingly,  they  did  not  take  the  approach  of  proving 
that  the  implementing  protocol  was  a  correct  imple¬ 
mentation  of  the  service  protocol.  Proving  only  that 
the  so-called  implementation  satisfies  the  desired 
properties  directly  u-,es  less  effort  than  proving  that 
the  so-called  implementation  is  in  fact  an  implemen¬ 
tation  and  then  to  deduce  by  transitivity  that  it  satis¬ 
fies  the  properties. 
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Graphic  Specification 

Another  operational  approach  is  that  of  Chen  and 
Yeh.  They  use  a  picture-based  model  that  directly 
exhibits  distribution  of  processes  typical  of  many 
concurrent  systems  these  days,  especially  protocols. 
One  draws  structure  diagrams  consisting  of  nested 
modules  (boxes)  connected  by  directed  arcs  emerg¬ 
ing  from  and  entering  into  modules  and  output  and 
input  sockets.  Figure  6  shows  a  typical  diagram 
consisting  of  a  single  module  called  RT  with  an  in¬ 
put  socket  1  and  an  output  socket  0.  A  module 
contains  some  computing  agent.  Messages  of  ar¬ 
bitrary  data  types  flow  along  the  arcs.  The  sockets 
represent  sets  of  message  arrival  events  at  the 
boundaries  of  the  module.  The  behavior  of  an  inner¬ 
most  module  is  described  by  giving  axioms  relating 
the  message  arrival  events  at  its  own  sockets.  These 
axioms  may  express  equality,  arithmetic.  Boolean, 
etc.  relations  between  contents  of  messages  as  well 
as  temporal  and  enabling  relations  on  the  events 
themselves.  Fo«-  example,  when  the  function  of  the 
RT  module  is  that  an  output  message  oe  0  that  ar¬ 
rives  at  the  output  socket  O  is  a  copy  of  an  input 
message  iel  that  arrived  at  the  input  socket  /,  then 

1 .  the  arrival,  i,  of  the  input  message  at  the  input 
socket  precedes  the  arrival,  o,  of  the  output 
message  at  the  output  socket: 

|-»0 

2.  i  enables  o: 

i=s>o 

3.  the  contents  of  /  and  o  are  the  same: 

i.cont  =  o.cont 

The  language  permits  existential  and  universal  quan¬ 
tification  of  events.  Thus  it  is  possible  to  express 
both  safety  and  liveness  properties.  The  “precedes” 
and  “enables"  relations  on  events  are  defined 
axiomatically.  For  example,  “precedes"  is  defined 
as  a  partial  ordering.  This  allows  defining  two 
events  as  concurrent  if  neither  can  be  shown  to 
precede  the  other.  Once  the  model  and  its  properties 
are  specified,  any  theorem  prover  that  can  handle 
axiomatic  definitions  can  be  used  to  carry  out  proofs 
of  property  satisfaction  by  the  model. 

The  paper  gives  a  protocol  service  specification  as  a 
single  module  with  one  input  and  one  output  socket 
The  relations  on  the  events  on  these  two  sockets 
describe  a  reliable  transmission  from  the  input  to  the 
output  socket.  The  paper  then  gives  a  specification 
of  the  AB  protocol  as  a  more  detailed  nest  of  mod¬ 
ules  which  contain  an  innermost  module  modeling 
an  unreliable  medium.  The  AB  protocol  is  proved  to 
implement  the  service  protocol  by  proving  the  rela¬ 
tions  that  specify  the  service  protocol  to  be  theorems 
in  the  AB  protocol  model.  Also  a  number  of  the 
usual  safely  and  liveness  properties  are  proved  of  the 
AB  protocol  model. 


4.  Other  Problems 

Hayes  has  edited  a  collection  of  case  studies  of  for¬ 
mal  specifications  [Hayes87],  Among  the  examples 
specified  are  a  telephone  network,  the  UNIX  file 
system,  several  reservation  systems,  and  several  dis¬ 
tributed  systems. 

V.  Doing  the  Verifications 

There  is  an  excellent  book  by  Howard  Barringer 
[Barringar85}  that  surveys  all  the  specification  and  veri¬ 
fication  methods  except  denotational  and  temporal. 
The  papers  by  Lamport  and  Owicki  [Lamport83a, 
Lamport83b,  Lamport86,  Owicki82]  on  the  topic  of  tem¬ 
poral  semantics  show  how  to  do  temporal  proofs.  The 
survey  article  by  Cheheyl,  Gasser,  Huff,  and  Millen 
[CheheylSl]  shows  how  the  various  operational  sys¬ 
tems  are  used.  The  detail  required  for  an  adequate 
coverage  precludes  their  inclusion  in  this  module 

VI.  Specification  Languages  and  Verification 
Environments 

Many  of  the  operational  semantic  languages  have  been 
implemented.  That  is,  for  these  languages,  there  exists 
a  specification  language  processor  which  given  a  speci¬ 
fication  and  a  list  of  properties  to  prove,  generates  con¬ 
jectures,  which  if  proved,  imply  the  holding  of  the 
properties.  Most  of  these  systems  also  come  with  in¬ 
teractive  or  semi-automatic  theorem  provers  that  can  be 
used  to  prove  the  conjectures  generated  from  a  specifi¬ 
cation.  In  fact,  these  tools  sit  in  environments  that  are 
directed  at  specifying  and  implementing  verifiably  cor¬ 
rect  systems. 

The  specification  and  verification  environments  sur¬ 
veyed  in  litis  module  are  representauve  what  is  avail¬ 
able: 

•  AFFIRM 

•  FDM 

•  Gypsy 

•  HDM 

•  P-NUT 

•  SARA 

•  PAISLey 

•  STATEMATE 

•  Process  Algebras 

•  ASTRAL 

Most  of  these  environments  have  actually  been  used  to 
carry  out  specifications  and  property  verifications  of 
real  software.  These  include  mamly  kernels  of  operat¬ 
ing  systems  that  are  supposed  to  enforce  security 
policies  and  protocols. 

For  each  language  and  environment  the  discussion  in¬ 
cludes  descriptions  of  as  much  of  the  following  as  is 
relevant. 

1.  the  language  itself 
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2.  how  one  specifies  an  NDISM  in  the  language 

3.  how  complete  the  specification  can  be 

4.  what  kinds  of  properties  can  be  proved  of  an 
NDISM 

5.  how  one  specifies,  if  at  all,  the  redundant 
properties  that  are  to  be  proved  of  an  NDISM 

6  the  associated  system  development  method 

7.  known  limitations  of  the  language  or  its  environ¬ 
ment 

8.  the  tools  of  the  environment 

9.  actual  system  developments  to  which  the  lan¬ 
guage  and  its  environment  have  been  applied 

Topics  1,  8,  and  9  get  their  own  subsections  and  topics 
2  through  7  are  covered  in  a  single  subsection  entitled 
“Specification  and  Verification". 

Each  of  these  is  described  by  literature  mentioned  in  its 
own  description  below.  There  are  some  surveys  that 
cover  more  than  one  of  these.  The  first  four  are  sur¬ 
veyed  very  thoroughly  by  Cheheyl,  Gasser,  Huff,  and 
Millen  [CheheylSt],  The  Cohen,  Harwood,  and  Jack- 
son  book  [Coh0n86]  has  brief  descriptions  of  AFFIRM, 
Gypsy,  HDM,  and  SARA.  The  Lindsey  survey 
[Lindsay88]  describes  a  number  of  automated  verifica¬ 
tion  environments,  including  AFFIRM  and  Gypsy. 

1.  AFFIRM 

Language 

AFFIRM  [ThompsonSI]  was  designed  by  USCs  In¬ 
formation  Sciences  Institute  (ISI)  as  a  system  for 
specifying  abstract  data  types  (ADTs)  [Liskov74]  and 
verifying  their  properties.  The  AFFIRM  language  is 
basically  a  notation  for  writing  algebraic  specifica¬ 
tions  of  abstract  data  types  [Guttag78].  First,  the 
signature  of  each  operation  of  the  ADT  is  given  in 
the  form  of  the  list  of  the  types  of  its  parameters  and 
the  type  of  its  return  value.  Then  a  set  of  axioms  are 
given  to  relate  the  values  of  various  applications  of 
the  operations. 

The  theorem  prover  uses  the  axioms  defining  an 
ADT  as  rewrite  rules.  Therefore,  there  are  restric¬ 
tions  on  the  form  of  the  axioms  to  make  sure  that 
their  applications  as  rewrite  rules  cannot  go  into  infi¬ 
nite  loops.  Among  the  restrictions  is  that  the  left 
side  should  consist  of  a  single  function  application 
and  that  the  right  side  should  be  have  at  least  as 
many  terms  as  the  left  side. 

Specification  and  Verification 

One  defines  an  NDISM  as  an  ADT  whose  data  arc 
the  snapshots  and  whose  operations  create  the  initial 
snapshot  and  perform  the  individual  h  ms  formations. 
That  is,  each  operation  except  the  create  operation 
accepts  a  snapshot  as  its  only  parameter  and  returns 
as  its  result  a  next  snapshot.  The  create  operation 
takes  no  parameter  and  returns  an  initial  snapshot. 


As  there  may  be  more  than  one  operation  applicable 
to  a  given  snapshot,  it  is  possible  to  model  nondeter- 
minism  The  operations  are  specified  algebraically, 
using  equational  axioms,  whose  left  and  right  sides 
contain  applications  of  operations,  including  the  cre¬ 
ate  operations. 

T  he  view  of  rules  as  rewrite  rules  is  interesting  when 
the  ADT  is  used  to  define  an  NDISM  Specifically 
application  of  a  rule  can  be  viewed  as  a  snapshot 
transformation,  i.e.,  as  taking  one  step  of  the  compu¬ 
tation.  Thus  a  computation  can  be  viewed  as  a  se¬ 
quence  of  rewrite  rule  applications  Concurrency  is 
modeled  when  there  is  no  unique  sequence  of  rewrit¬ 
ings,  that  is  when  which  rule  is  applied  next  is  non- 
deterministic 

The  AFFIRM  language  permits  universal  and  ex¬ 
istential  quantification  over  the  values  of  the  abstract 
data  type  Therefore,  it  is  possible  to  express  both 
safety  and  hveness  properties  in  AFFIRM  specifi¬ 
cations  of  NDISMs. 

Tools 

The  AFFIRM  environment  contains  a  number  of 
useful  tools,  including 

•  an  algebraic  specification  analyzer. 

•  a  library  of  useful  data  type  specifications, 

•  a  library  of  useful  proofs, 

•  a  theorem  prover,  and 

•  a  friendly  user  interface. 

The  specifications  analyzer  attempts  to  check  that 
the  specification  meets  certain  well-formedness 
properties  such  as  suitability  as  rewrite  rules  and 
completeness.  It  can  only  attempt  a  completeness 
check,  because  in  general  completeness  of  an  axiom 
set  is  undecidablc.  The  theorem  prover  allows  inter¬ 
active  natural  deduction.  Die  user  enters  the 
relevant  ADT  specifications  and  then  gives  it  con¬ 
jectures  about  these  data  types  to  prove. 

Actual  Use 

AFFIRM  has  been  used  to  specify  and  prove 
properties  of  a  number  of  network  protocols 
[Sunshine82].  The  properties  proved  include  both 
safety  and  liveness  properties.  AFFIRM  was  also 
used  in  the  Delta  Experiment  [Gerhart79]  The  Delta 
system  is  part  of  the  Military  Message  System 
(SIGMA).  It  is  a  collection  of  functions,  about  1000 
lines  of  BLISS  code,  for  reading  and  appending 
comments  to  messages  in  a  secure  manner  The  col¬ 
lection  was  specified  as  operations  of  a  message 
ADT.  Certain  security  properties  were  proved.  An 
abstract  implementation  was  written  and  proved  cor¬ 
rect.  This  abstract  program  was  generated  by  hand 
from  the  original  BLISS  language  programs  of  the 
system. 
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2.FDM 

The  Formal  Development  Method  (FDM)  [Eggert89, 
Barton88,  Eckmann89,  Holtsberg89]  was  developed 
by  Unisys  (which  absorbed  System  Development 
Corporation)  for  use  in  specifying  systems  and  veri¬ 
fying  that  they  satisfy  desired  properties  The  lan¬ 
guage  of  FDM  is  the  Ina  Jo  language  [Locasso80, 
Scheid86a,  Scheid86b,  Scheid89], 

Language 

The  Ina  Jo  language  allows  a  direct  specification  of 
NDISM  by  giving  assertions  relating  before  and  af¬ 
ter  snapshots  of  individual  selectable  transfor¬ 
mations.  The  language  permits  quantification  over 
values  of  snapshot  variables  but  not  over  snapshots 
themselves. 

Specification  and  Verification 

An  Ina  Jo  specification  consists  of  a  list  of  level 
specifications.  The  first  of  these  is  called  the  Top 
Level  Specification  (TLS),  and  the  last  of  these  is 
called  the  implementation  specification.  Each  level 
specification  consists  of  four  main  parts 

•  data  declarations 

•  initial  conditions 

•  transform  specifications 

•  correctness  assertions 

•  mapping  specification  (except  in  the  TLS) 

The  data  declarations  declare  the  types  of  values 
used  by  the  variables  and  the  variables  appearing  in 
the  snapshot  (“state"  in  FDM  terminology),  and  the 
possibly  parameterized  snapshot  interrogation  func¬ 
tions. 

The  initial  conditions  describe  by  assertion  all  the 
possible  legal  initial  snapshots. 

The  transform  specifications  describe  for  each  trans¬ 
form  the  conditions  under  which  it  may  be  invoked 
and  how  the  before  and  after  snapshots  are  related; 
these  relations  can  be  functional,  but  they  do  not 
have  to  be. 

The  correctness  assertions  are  redundant  assertions 
of  two  kinds,  criteria  and  constraints.  Each  criterion 
is  a  one-snapshot  assertion  that  is  supposed  to  be  an 
invariant,  and  each  constraint  is  a  two-snapshot 
assertion  that  is  supposed  to  be  satisfied  by  all  trans¬ 
forms. 

All  levels  except  the  TLS  have  a  mapping  section 
which  explains  how  to  write  expressions  of  the  lan¬ 
guage  of  the  preceding  level,  i.e.,  its  parent  level,  in 
the  language  of  its  own  level.  This  is  to  allow  an 
assertion  of  the  parent  level  to  be  rewritten  in  the 
language  of  the  child  level  in  order  to  see  if  it  can  be 
proved  a  theorem  in  the  child  level.  In  this  manner, 


the  redundant  specifications,  discussed  below,  of  the 
parent  level  can  be  proved  to  hold  in  the  child  level. 

The  FDM  suggests  the  following  way  of  designing  a 
secure  system.  The  designer  starts  with  the  writing 
of  the  TLS.  He  or  she  decides  on  the  data  of  its 
snapshot,  on  its  initial  conditions,  and  on  its  security 
policy  as  expressed  by  criteria  and  constraints  in¬ 
volving  the  variables  of  the  snapshot. 


The  designer  then  begins  an  iterative  process  by 
which  transforms  are  added  until  the  model  has  all 
the  desired  transforms  and  all  of  them  preserve  the 
criteria  and  satisfy  the  constraints.  As  a  transform  is 
added,  it  should  be  verified  as  preserving  the  criteria 
and  satisfying  the  constraints.  If  not,  then  the  trans¬ 
form  must  be  changed  until  the  verification  suc¬ 
ceeds.  As  the  set  of  transforms  is  being  decided 
upon,  the  designer  may  also  choose  to  start  supply¬ 
ing  more  implementation  details.  In  this  case,  the 
designer  specifies  a  new  level  in  which  the  data  vari¬ 
ables  exhibit  more  implementation  details  The 
designer  writes  the  entire  level,  the  data,  the  initial 
conditions,  and  the  transforms  so  as  to  implement 
the  parent  level.  The  way  in  which  the  child  data 
implements  the  parent  data  is  captured  in  the  map¬ 
ping  section  of  the  child  level. 


Because  of  the  great  difficulty  in  carrying  out  de¬ 
tailed  proofs  of  implementation  correctness,  the 
designers  of  the  FDM  have  stuck  to  more  modest 
goals.  Specifically,  it  is  required  only  to  prove  that 
the  child  level  satisfy  the  criteria  and  the  constraints 
of  the  TLS  that  define  the  correctness  of  the  model. 
Rather  than  prove  the  child  level  a  correct  imple¬ 
mentation  of  the  parent  level  through  its  mapping, 
each  successive  level  starting  with  the  child  of  the 
TLS  is  shown  to  satisfy  the  mapped  criteria  and  con¬ 
straints  of  the  11. S  brought  down  through  its  parent. 


Consistent  with  this  method  of  adding  more  trans¬ 
forms,  the  set  of  computations  defined  by  an  Ina  Jo 
level  specification  is  not  necessarily  that  generated 
by  applying  arbitrary  compositions  of  transforms  to 
the  snapshots  satisfying  the  initial  conditions.  The 
set  of  computations  is  a  superset  of  these  and  a  sub¬ 
set  of  those  generated  by  applying  the  arbitrary  com¬ 
position  of  the  constraints,  considered  as  transforms, 
to  the  snapshots  satisfying  the  initial  conditions. 
While  it  is  never  known  if  there  will  not  be  more 
transforms  added  later,  it  is  known  that  all  those 
added  later  will  satisfy  the  constraints. 


Because  the  redundant  assertions  are  invariants  and 
constraints,  one  can  specify  and  prove  safety 
properties  and  relations  between  successive  snap¬ 
shots.  Because  there  is  no  quantification  over  snap¬ 
shots,  one  cannot  specify  and  prove  liveness 
properties  in  the  Ina  Jo  language. 
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Tools 

The  FDM  is  supported  by  an  environment,  the  FDM 
platform,  which  includes  a  number  of  tools,  the  most 
important  of  which  are  the  following: 

•  Ina  Jo  processor 

•  Interactive  Theorem  Prover  (ITP) 

The  Ina  Jo  processor  is  essentially  a  compiler.  It 
checks  input  Ina  Jo  specification  for  syntax  and  type 
errors,  and  if  none  are  found,  it  generates  a  set  of 
conjectures,  one  for  each  level  specification.  These 
conjectures  imply  that 

•  the  initial  conditions  satisfy  the  possibly  mapped 
criteria, 

•  the  transforms  preserve  the  possibly  mapped  cri¬ 
teria,  and 

•  the  transforms  satisfy  the  possibly  mapped  con¬ 
straints. 

In  other  words,  if  the  conjectures  are  verified,  then 
the  NDISM  specified  by  the  data  declarations,  the 
initial  conditions,  and  the  transform  specifications 
have  been  shown  to  meet  the  correctness  conditions 
as  given  by  the  redundant  assertions. 

The  ITP  [SteinSO,  Smith86]  is  used  in  order  to  at¬ 
tempt  to  prove  these  conjectures.  The  ITP  first 
generates  the  logical  negation  of  the  conjecture  to  be 
proved;  then  the  ITP  helps  the  user  find  a  contradic¬ 
tion  thus  proving  the  original  conjecture  a  theorem. 

Actual  Use 

Despite  the  original  intention  of  being  able  to  carry 
out  the  FDM  over  several  levels  down  to  code,  no 
application  has  even  been  carried  out  over  more  than 
2  levels  and  no  application  has  been  carried  to  code. 
In  order  to  carry  out  the  FDM  all  the  way  to  code, 
another  tool  is  needed  for  each  programming  lan¬ 
guage  the  might  be  used  in  conjunction  with  the 
FDM,  namely  a  verification  condition  generator 
(VCG)  [Scheid83a,  Scheid83b]  that  generates  verifi¬ 
cation  conditions  asserting  that  a  given  procedure 
body  implements  a  given  transform  as  specified  in 
the  implementation  level  specification.  Unfor¬ 
tunately,  to  date,  there  is  no  complete  VCG  for  any 
programming  language. 

The  FDM  has  been  applied  to  specify  and  prove  the 
data  security  of  a  number  of  system  programs.  One 
of  these  was  the  AUTODIN  II  multi-level  secure 
packet  switching  network  [CheheylSI].  The  second 
of  these  was  for  KVM/370  a  secure  kemelized  ver¬ 
sion  of  VM/370  [Gold79].  In  both  of  these  cases,  the 
top  level  was  proved  to  meet  the  specified  security 
requirements.  Neither  was  carried  to  any  addition^ 
levels. 

3.  Gypsy 

The  Gypsy  Verification  Environment  (GVE)  was 


developed  by  a  group  of  people  at  the  University  of 
Texas  at  Austin  [Good78,  Ambler78,  Good84a, 
Good84b],  Whereas  the  emphasis  of  AFFIRM, 
FDM,  and  HDM  are  on  verification  that  a  specifi¬ 
cation  and  a  design  meet  stated  requirements,  the 
emphasis  of  the  GVE  is  on  verification  that  an  im¬ 
plementation  is  correct  to  stated  requirements.  The 
GVE  has  been  used  for  code  correctness  proofs, 
which,  in  general  have  not  been  done  in  any  actual 
application  of  AFFIRM,  FDM,  and  HDM 

Language 

The  language  of  the  GVE  is  Gypsy.  Consistent  with 
the  emphasis  of  the  GVE,  Gypsy  is  a  Pascal-like 
language  that  can  be  used  both  for  specification  and 
for  implementation.  There  are  restrictions  from  Pas¬ 
cal  and  extensions  to  Pascal  in  Gypsy.  The  restric¬ 
tions  are  for  the  purpose  of  eliminating  features  that 
cause  anomalies  to  the  standard  Hoare  axiom  sys¬ 
tem.  For  example,  no  function  or  procedure  ac¬ 
cesses  any  non-local  variable,  all  accesses  to  a  vari¬ 
able  otlier  than  local  variables  must  be  via  variable 
parameters.  Functions  have  only  by-value 
parameters  and  thus  cannot  have  side  effects.  Proce¬ 
dures  that  do  not  return  values  can  have  side  effects 
only  through  their  parameters.  On  the  extension 
side,  there  is  a  syntax  for  assertions  that  can  be  at¬ 
tached  to  arbitrary  points  in  the  program  as  well  as 
at  procedure  and  function  headings  as  interface 
specifications. 

Specification  and  Verification 

In  Gypsy  one  specifies  NDISMs  solely  in  an  indirect 
manner  by  writing  a  program  that  implements  it.  In 
order  to  obtain  concurrency,  Gypsy  has  a  number  of 
features  for  setting  up  processes  and  for 
synchronization. 

Tools 

The  GVE  has  a  number  of  tools: 

•  Gypsy  syntax  directed  editor 

•  Gypsy  parser 

•  Gypsy  interpreter 

•  Gypsy  compiler 

•  Gypsy  optimizer 

•  verification  condition  generator  (VCG) 

•  theorem  prover 

Controlling  all  of  these  is  the  GVE  executive.  It  is 
worth  noting  that  the  optimizer  uses  knowledge  that 
can  be  gleaned  from  the  assertions  in  making  op¬ 
timization  decisions;  for  example,  if  the  assertions 
imply  that  one  arm  of  a  conditional  is  impossible  to 
ever  follow,  its  code  is  not  generated. 

The  VCG  generates  conjectures  which  imply  that 
the  code  is  partially  correct  with  respect  to  the  asser¬ 
tions  given  as  annotations  in  the  code.  Because  of 
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its  basis  on  the  Hoare  axiom  system,  safety 
properties  can  be  proved.  This  author  believes  that 
certain  liveness  properties  such  as  halting  are  also 
proved,  but  not  by  conjectures  generated  by  the 
VCG.  These  have  to  be  submitted  directly  to  the 
theorem  prover 

The  GVE  uses  a  Boyer-Moore  theorem  prover. 

Actual  Use 

The  GVE  has  been  used  for  a  secure  network  appli¬ 
cation  [Gaod82j.  That  is  the  software  that  encrypts 
messages  prior  to  sending  them  out  over  a  non- 
secure  network  and  that  decrypts  received  messages 
only  for  the  stated  recipient.  It  was  verified  that 
only  encrypted  messages  get  out  into  the  network, 
and  that  all  received  messages  are  equal  to  the  cor¬ 
responding  original  message.  The  GVE  was  also 
used  to  develop  the  ACCAT  guard.  The  ACCAT 
guard  is  used  to  assist  a  human  being  in  downgrad¬ 
ing  documents  from  a  higher  security  level  to  a 
lower  one.  It  is  proved  that  no  data  are  downgraded 
unless  the  human  operator  has  seen  it;  thus  it  is 
presumed  that  the  human  is  cleared  to  the  higher 
security  level  and  is  competent  to  decide  on  the  sen¬ 
sitivity  of  the  document  and  to  excise  portions  that 
should  not  be  released  to  those  who  are  cleared  for 
the  lower  security  level.  For  both  of  these  projects 
the  security  criteria  was  stated  as  Gypsy  assertions 
and  the  code  was  written  in  Gypsy. 

More  recently,  the  people  responsible  for  the  GVE 
have  moved  in  other  directions.  One  such  direction 
is  to  use  the  Boyer-Moore  logic  directly  to  to  specify 
both  an  abstraction  and  an  implmentation  as 
NDlSMs  and  to  prove  the  correctness  of  the  imple¬ 
mentation  of  the  abstraction  by  showing  that  the  lat¬ 
ter  simulates  the  former  as  suggested  in  Section 
III.  1  .d  [Bevier87].  The  Boyer-Moore  prover  has  also 
been  used  to  mechanize  a  proof  system 
[Goldschlag90a,  Goldschlag90b],  defined  in  the 
Boyer-Moore  logic,  for  UNITY  [Chandy88]. 

4.  HDM 

The  Hierarchical  Development  Method  (HDM)  was 
developed  at  SRI  International  for  the  purpose  of 
specifying  and  verifying  the  security  of  operating 
system  kernels  {Robinson79,  Silverberg79].  Operat¬ 
ing  systems  arc  developed  by  hierarchical  decom¬ 
position  and  the  kernels  are  multi-level  secure.  The 
hierarchical  decomposition  of  the  system  is  carried 
out  using  traditional  software  engineering  methods; 
for  example,  information  hiding  is  used  to  decide 
how  to  decompose  a  system  into  modules,  and  each 
module  is  made  an  abstract  machine  providing  some 
service,  such  as  memory  management,  to  the  other 
abstract  machines.  Each  such  abstract  machine  is 
specified  as  an  NDISM  using  SPECIAL. 


Language 

The  specification  language  of  the  HDM  is  SPE¬ 
CIAL.  SPECIAL  allows  direct  specification  of 
NDISMs.  A  SPECIAL  specification  of  an  NDISM 
consists  of  two  main  parts, 

•  the  data  part,  and 

•  the  algorithm  part. 

The  data  part  declares  types  used  by  the  variables 
and  the  variables  of  the  snapshot  of  the  NDISM 
Each  data  type  is  specified  algebraically  with 
axioms. 

The  algorithm  part  consists  of  a  collection  of  opera¬ 
tion  specifications.  There  are  two  kinds  of  opera¬ 
tions,  VFUNs  and  OFUNs.  VFUNs  are  value  func¬ 
tions;  they  return  values  computed  from  the  current 
values  of  variables  and  have  no  side  effects  on  these 
variables.  OFUNs  are  procedures  that  change  the 
values  of  variables  and  do  not  return  values.  Their 
notation  is  not  unlike  that  of  Pamas’s  (Pamas72b), 
and  indeed  the  HDM  designers  suggest  using  the 
same  software  design  methods  touted  by  Pamas  in 
the  same  and  related  papers  lPamas72a], 

Specification  and  Verification 

In  the  HDM  terminology,  the  specification  of  an 
NDISM  is  a  Top  Level  System  (TLS).  The  TLS 
specifies  the  visible  behavior  of  the  system,  which 
the  users  of  the  abstract  machine  can  rely  upon.  Be¬ 
low  the  TLS,  is  a  list  of  NDISMs  each  of  which  is  a 
refinement  of  the  one  above  it.  A  refinement 
NDISM  provides  more  implementation  details  than 
the  one  above  it,  but  provides  no  new  operations;  to 
do  so  would  violate  the  TLS's  specifying  the  visible 
behavior  of  the  system.  Below  the  lowest  level 
comes  the  implementation  of  the  specified  TLS  as  a 
module  or  a  collection  of  procedures  and  data  struc¬ 
tures  in  some  implemented  programming  language. 

Tools 

There  are  no  redundant  properties  mentioned  in  a 
SPECIAL  specification.  Instead  the  properties  to  be 
proved  are  provided  by  the  prover  at  proof  time  to 
the  verifier.  Given  the  basic  purpose  of  the  HDM  to 
be  able  to  prove  systems  multi-level  secure  (MLS), 
there  is  an  MLS  Formula  Generator  which  takes  a 
TLS  and  generates  conjectures  which  collectively 
imply  the  multi-level  security  of  the  TLS.  The  MLS 
Formula  Generator  is  based  on  Feiertag’s 
[Feiertag80]  model  of  multi-level  security. 

These  conjectures  can  be  submitted  along  with  the 
TLS  to  the  Boyer-Moore  theorem  prover  that  is 
available.  The  user  of  the  theorem  prover  may  also 
interactively  provide  other  conjectures  to  prove,  thus 
allowing  him  or  her  to  prove  properties  other  than 
multi-level  security. 
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While  the  TLS  is  to  be  demonstrated  MLS,  the  re¬ 
finement  levels  are  to  be  proved  conrect  implemen¬ 
tations  of  their  immediate  parents.  This  proof  is 
based  on  die  standard  mapping  from  the  implement¬ 
ing  level’s  data  to  the  implemented  level’s  data  de¬ 
scribed  in  Section  Il.l.d.  In  addition  the  code  im¬ 
plementing  a  TLS  is  to  be  proved  correct  by  proving 
each  procedure  a  correct  implementation  of  the  cor¬ 
responding  operation  in  the  lowest  level  refinement 
of  the  TLS.  For  each  implementing  programming 
language  there  is  supposed  to  be  a  verification  con¬ 
dition  generator  (VCG)  that  generates  conjectures 
implying  this  correctness  relation.  At  present  there 
are  VCGs  for  Pascal,  FORTRAN,  and  JOVIAL.  In 
order  not  to  have  to  develop  a  VCG  for  every  pro¬ 
gramming  language  that  might  be  used,  SRI  has  de¬ 
veloped  a  Common  Internal  Form  (CIF)  which  can 
express  implementations  and  whose  programs  can 
be  translated  straightforwardly  to  any  implementa¬ 
tion  language.  They  have  written  a  VCG  for  CIF  as 
the  implementing  language.  Currently  translation 
from  CIF  notation  to  an  implemented  programming 
language  is  done  by  hand. 

Actual  Use 

The  HDM  has  been  used  to  specify,  design,  and  ver¬ 
ify  MLS  secure  two  operating  systems,  Kemelized 
Secure  Operating  System  (KSOS)  (McCauley 79]  and 
Provably  Secure  Operating  System  (PSOS) 
[Neumann77,  Feiertag79], 

5.  P-NUT 

P-NUT  is  a  suite  of  tools  developed  by  the  Distri¬ 
buted  Systems  Project  at  University  of  California  at 
Irvine  [Razouk85a,  Razouk85b,  Morgan87].  The 
purpose  of  these  tools  is  to  allow  design  of  concur¬ 
rent  systems  in  a  manner  that  allows  detection  of 
timing,  synchronization,  and  resource  contention  er¬ 
rors.  The  approach  used  is  to  specify  these  systems 
with  analyzable  models  and  to  have  tools  which  do 
the  analysis.  P-NUT  is  built  around  giving  Petri  net 
models  of  concurrent  systems  [PetersonSI], 

Language 

A  Petri  net  is  a  bipartite  directed  graph  whose  nodes 
are  transitions  and  places.  Figure  7  shows  a  Petri 
net  describing  a  service  protocol.  The  places  PI  and 
P2  send  messages  to  each  other  via  the  transitions 
71  and  72.  The  directed  arcs  indicate  for  each  tran¬ 
sition  which  places  are  input  places  and  which 
places  are  output  places,  namely  those  places  which 
are  at  the  tail  and  heads  of  the  arcs  respectively. 

A  snapshot  in  a  Petri  net  computation  consists  of  an 
assignment  of  zero  or  more  tokens  to  each  place.  A 
transition  is  fireable  if  there  is  at  least  one  token  on 
each  of  its  input  places.  If  a  transition  fires,  then 
one  token  is  removed  from  each  input  place  and  one 
token  is  deposited  at  each  of  its  output  places  to 


create  the  token  assignment  of  the  next  snapshot.  At 
each  snapshot  any  Fireable  transition  may  be  se¬ 
lected  for  firing.  Thus  concurrency  is  modeled  by 
having  more  than  one  transition  fireable. 

A  Petri  net  may  be  timed  or  unumed.  Normally  a 
Petri  net  is  untimed.  When  it  is  timed,  a  delay  is 
associated  with  each  transition  indicating  how  long 
it  takes  for  the  transition  to  fire.  A  Petri  net  may 
also  be  interpreted  or  uninterpreted  Normally  it  is 
uninterpreted,  but  one  may  associate  an  actual  func¬ 
tion  with  a  transition.  In  this  case,  each  token 
represents  one  parameter.  Thus  these  functions  are 
not  applied  unless  all  input  parameters  have  been 
supplied. 

Specification  and  Verification 

A  system  is  specified  by  giving  a  Petri  net  for  it. 
This  Petri  net  can  be  totally  uninterpreted;  however, 
then  not  much  beyond  its  flow  control  is  specified. 
More  information  can  be  given  in  the  form  of  timing 
estimates  for  the  firing  of  places  and  interpretations, 
i.e.,  procedures,  that  explain  what  happens  when  a 
place  fires. 

Toots 

The  P-NUT  environment  contains  a  variety  of  tools, 
including 

•  an  interactive  graphic  Petri  net  editor, 

•  a  translator, 

•  an  untimed  reachability  graph  builder, 

•  a  timed  reachability  graph  builder, 

•  a  reachability  graph  analyzer, 

•  a  reachability  graph  pretty  printer,  and 

•  a  simulator. 

The  translator  converts  a  Petri  net  input  in  linear 
form  into  an  intermediate  form  which  is  used  by  all 
the  other  tools  to  stand  for  the  net. 

The  reachability  graph  builders  build  graphs  whose 
nodes  are  all  the  snapshots  achievable  in  any  compu¬ 
tation  of  a  candidate  Petri  net.  The  builders  try  to 
keep  these  graphs  finite  by  recognizing  when  a 
newly  generated  state  is  the  same  as  one  it  Las  seen 
before. 

These  reachability  graphs  are  analyzed  for  timing, 
synchronization,  resource  contention,  and  deadlock 
problems  by  the  reachability  graph  analyzer  (RGA). 
The  RGA  is  the  most  important  tool  of  P-NUT. 
With  it,  the  user  can  specify  propositions  and  predi¬ 
cates  about  places,  transitions,  and  arcs  in  the  Petri 
net  and  about  reachable  states  in  the  reachability 
graph.  AH  of  these  entities  can  also  be  bound  by 
both  the  existential  and  universal  quantifier.  There¬ 
fore  both  safety  and  liveness  properties  can  be  speci¬ 
fied.  The  RGA  proves  these  by  exhaustive  examina¬ 
tion  of  the  reachability  graph.  There  arc  also  a  num- 
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ber  of  generic  properties  that  the  RGA  knows  how 
to  demonstrate: 

•  boundedness,  that  there  is  some  constant  max¬ 
imum  number  of  tokens  at  each  place 

•  safeness,  that  there  is  a  maximum  of  one  token  at 
each  place 

•  conservation,  that  the  total  number  of  tokens  in 
any  snapshot  is  less  than  or  equal  to  some  con¬ 
stant 

•  liveness,  that  a  particular  transition  is  potentially 
ftreable  in  all  reachable  snapshots 

•  deadlock-freeness,  that  it  is  not  the  case  that  no 
transition  is  alive 

The  simulator  takes  a  graph  in  intermediate  form 
and  an  initial  assignment  of  tokens  and  simulates 
computations  by  firing  ftreable  nodes  and  redistrib¬ 
uting  tokens  according  to  the  firings.  If  the  net  is 
timed  the  simulator  will  keep  hack  of  simulated 
time.  If  the  net  is  interpreted,  the  simulator  will 
invoke  the  procedure  for  fired  nodes  and  keep  track 
of  the  values  of  the  tokens.  There  are  useful  facil¬ 
ities  for  controlling  the  progress  of  the  simulation. 
The  user  may  choose  which  node  to  fire,  or  he  or  she 
may  let  the  simulator  select  one  at  random. 

The  interactive  graphic  Petri  net  editor  allows  input¬ 
ting  nets  by  drawing  them  with  the  aid  of  a  mouse. 
This  is  more  convenient  than  the  linear  form  of  the 
graph  consisting  of  ordered  pairs  defining  the  arcs. 

Actual  Use 

The  tools  of  P-NUT  have  been  used  to  specify 
protocols  and  to  prove  both  safety  and  liveness 
properties  about  them.  Ilie  paper  by  Morgan  and 
Razouk  [Morgan87]  shows  a  specification  of  the  Al¬ 
ternating  Bit  (AB)  protocol  and  proof  of  its 
properties.  There  is  a  service  specification  as  a 
fairly  simple  Petri  net  and  then  a  very  detailed  Petri 
net  describing  the  AB  protocol  as  an  implementation 
of  the  service  specification.  With  the  help  of  the 
RGA,  the  AB  protocol  Petri  net  is  proved  to  satisfy 
the  liveness  property  of  implementing  the  service 
specification.  The  AB  protocol  Petri  net  is  also 
shown  to  be  safe,  so  that  the  readers  are  mutually 
exclusive. 

6.  SARA 

The  SARA  design  environment  was  developed  at 
UCLA  to  support  requirement-driven  top-down  de¬ 
sign  of  possibly  concurrent  digital  systems 
[Razouk77,  Vernon80,  Razouk80,  Estrin  86],  The 
SARA  method  dictates  top-down  design  from  re¬ 
quirements  until  the  level  at  which  it  is  possible  to 
compose  the  system  from  off-the-shelf  components. 

Language 

At  the  topmost  level  or  at  each  refinement  of  a  mod¬ 


ule,  one  gives  multiple  models  of  the  system  or 
module  at  hand,  each  from  a  slightly  different  point 
of  view.  The  models  are  structural  and  behavioral, 
and  there  is  a  mapping  between  behavior  model  ele¬ 
ments  and  the  supporting  structure  model  elements. 
A  structure  model  (SM)  consists  a  number  of  nested 
modules  (boxes)  connected  by  undirected  arcs  that 
meet  the  modules  only  at  sockets.  Figure  8  shows 
an  SM  on  the  lefthand  side  with  two  modules,  Ml 
and  M2,  and  an  arc  connecting  them  at  sockets  Ob¬ 
serve  that  the  modules  are  mapped  via  dashed  lines 
to  elements  in  the  rest  of  the  diagram.  The  behavior 
model,  in  the  form  of  a  graph  model  of  behavior 
(GMB)  consists  of  three  submodels, 

•  a  control  flow  graph  (CFG), 

•  a  data  flow  graph  (DFG),  and 

•  an  interpretation. 

The  two  flow  graphs  together  form  an  uninterpreted 
model.  Figure  8  shows  a  GMB  on  the  righthand 
side. 

The  CFG  consists  of  process  nodes  connected  by 
directed  arcs.  An  arc  represents  precedence  of  ac¬ 
tivation  of  the  processes  at  the  head  and  tail;  that  is, 
the  process  at  the  tail  must  finish  before  the  process 
at  the  head  can  begin.  Each  CFG  node  may  have 
more  than  one  in-pointing  arc  headed  at  it  and  more 
than  one  out-pointing  arc  tailed  at  it.  For  a  given 
node,  the  in-pointing  arcs  are  either  in  an  “and”  or 
an  “or”  relation,  and  likewise  for  the  out-pointing 
arcs.  These  relations  constitute  the  input  and  output 
logics  for  the  process  node,  respectively.  The  CFG 
in  the  GMB  of  Figure  8  has  two  process  nodes.  PI 
and  P2,  connected  by  two  arcs  flowing  in  opposite 
directions. 

A  snapshot  in  the  compulation  of  a  CFG  is  an  as¬ 
signment  of  zero  or  more  tokens  to  each  arc.  In  any 
snapshot  a  process  node  is  enabled  if  the  tokens  on 
its  in-pointing  arcs  satisfy  the  logic;  that  is,  if  the 
logic  on  the  in-pointing  arcs  is  "or",  then  at  least  one 
such  arc  has  at  least  one  token,  and  if  the  logic  is 
“and”,  then  all  such  arcs  have  at  least  one  token.  In 
each  snapshot,  any  enabled  process  node  is  selected 
for  initiation,  and  execution.  The  next  snapshot  is 
obtained  by  removing  tokens  from  the  initiated 
process's  in-pointing  arcs,  according  to  the  input 
logic,  and  depositing  tokens  on  the  process's  out¬ 
pointing  arcs,  according  to  the  output  logic.  That  is, 
if  the  input  logic  is  “or”,  then  exactly  one  token  is 
removed  from  exactly  one  of  the  in-pointing  arcs, 
and  if  the  input  logic  is  “and”,  then  exactly  one 
token  is  removed  from  each  of  the  in-pointing  arcs. 
Similarly,  if  the  output  logic  is  “or”,  then  exactly 
one  token  is  deposited  on  exactly  one  of  the  out¬ 
pointing  arcs,  and  if  the  output  logic  is  “and",  then 
exactly  one  token  is  deposited  on  each  of  the  out¬ 
pointing  arcs. 
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The  DFG  is  a  bipartite  composed  of  process  and 
dataset  nodes.  An  arc  with  the  head  at  a  process 
represents  the  dataset  at  the  tail  being  an  input  to  the 
process,  and  an  arc  with  the  tail  at  a  process 
represents  the  dataset  at  the  head  being  an  output  of 
the  process.  Each  DFG  process  is  associated  with 
some  process  in  the  CFG  so  that  a  DFG  process  is 
initiated  to  do  its  data  transformation  from  input  to 
output  when  the  corresponding  CFG  is  initiated. 
The  DFG  of  the  GMB  of  Figure  8  has  two  process 
nodes,  PI  and  FI,  and  two  dataset  nodes,  D1  and 
D2.  All  the  arcs  flow  from  one  kind  of  node  to  the 
other.  Observe  that  an  association  has  been  set  up 
mapping  the  DFG  processes  PI  and  P2  to  the  CFG 
processes  PI  and  P2  respectively. 

Associated  with  each  process  node  in  the  CFG  may 
be  an  interpretation,  a  procedure  in  some  imple¬ 
mented  programming  language,  LISP  in  the  current 
version  of  SARA,  describing  the  behavior  of  the 
process.  The  input  and  output  of  this  procedure 
must  be  consistent  with  the  connectivity  of  the 
process’s  associate  in  the  DFG. 

Specification  and  Verification 

The  design  and  implementation  of  a  system 
proceeds  from  requirements  downward  to  imple¬ 
mentation  using  components,  including  program¬ 
ming  language  statements,  off  the  shelf.  The  re¬ 
quirements  are  stated  as  an  enumerated  list  of  natu¬ 
ral  language  sentences,  the  numbering  giving  a 
means  to  map  implementation  details  to  the  require¬ 
ments  that  they  help  implement.  The  topmost  level 
design  is  a  complete  complement  of  designs  in  each 
of  SARA's  languages.  The  tools  described  below 
give  means  to  analyze,  simulate,  and  lest  the  design. 
As  the  designer  moves  from  level  to  level,  he  or  she 
takes  a  yet  unimplemented  SM  module  and  either 
implements  it  easily  with  off-the-shelf  components 
or  refines  it  into  a  complete  complement  of  models 
giving  more  details.  This  process  continues  until  the 
system  is  completely  tested  and  implemented. 


The  SARA  environment  is  a  graphics  based  environ¬ 
ment  in  which  one  can  draw  the  models  and  estab¬ 
lish  the  mappings  and  associations  between  elements 
of  the  models  visually.  Figure  8  shows  these  map¬ 
pings  as  dashed  lines.  In  this  environment,  there  are 
a  variety  of  tools  that  can  be  used  to  validate  the 
models,  in  particular  the  GMB  models, 

•  GMB  Analyzer  for  analyzing  the  CFG  in  order 
to  test  for  proper  termination  and  thus  for  dead¬ 
lock, 

•  Performance  Analyzer  for  a  stochastic  variant  of 
the  CFG,  and 

•  GMB  Simulator  for  allowing  the  user  to  exercise 
the  model  with  visual  feedback. 


The  GMB  Analyzer  generates  the  graph  of  all  reach¬ 
able  states  and  then  asks  various  questions  that  can 
be  answered  by  examining  the  structure  of  this 
graph. 

The  Performance  Analyzer  uses  supplied  timing  in¬ 
formation  to  build  a  closed  form  queueing  theory 
model  of  the  CFG. 

The  GMB  Simulator  is  in  the  form  of  a  token  ma¬ 
chine.  It  implements  the  token-distribution  seman¬ 
tics  of  the  GMB  model,  allowing  the  user  to  choose 
among  enabled  nodes,  and  it  invokes  associated  in¬ 
terpretation  procedures  as  process  nodes  are  in¬ 
itiated.  The  token  machine  shows  the  simulation  on 
the  screen  by  highlighting  initiated  nodes  and  show¬ 
ing  tokens  moving  from  arc  to  arc. 

Actual  Use 

The  models  of  SARA  have  been  used  to  describe 
protocols,  and  the  tools  of  the  SARA  environment 
have  been  used  to  verify  certain  useful  properties  of 
these  protocols,  such  as  proper  termination 
[Razouk79,  Ruggiero79],  The  SARA  tools  do  not 
permit  verification  of  correctness,  since  the  require¬ 
ments  language  is  only  natural  language. 

7.  PAISLey 

PAISLey  (Zave72,  Zave87a,  Zave87b,  Zave87c, 
Zave91]  is  an  executable  specification  language  for 
specifying  concurrent  digital  systems.  That  is,  be¬ 
sides  formally  specifying  a  concurrent  system,  a 
PAISLey  definition  can  be  given  to  an  interpreter 
that  will  execute  the  specification  to  produce  one  or 
more  of  the  specified  computations. 

It  is  claimed  that  PAISLey  is  different  from  an  ordi¬ 
nary  programming  language  because  a  specification 
in  PAISLey,  when  it  can  be  given,  is  implementation 
independent.  That  is,  it  can  describe  all  required 
properties  and  behavior  of  a  digital  system  only  to 
the  level  of  detail  desired,  leaving  all  other  aspects, 
including  how  the  properties  and  behavior  are  im¬ 
plemented,  unspecified.  For  example,  instead  of  de¬ 
scribing  a  computation  over  all  the  elements  of  a  list 
as  a  loop  that  visits  the  elements  in  some  order,  the 
result  of  this  computation  is  specified  using  univer¬ 
sal  quantification  over  the  elements  of  the  list 

PAISLey  tries  to  get  the  best  of  two  computational 
models,  asynchronously  interacting  concurrent  proc¬ 
esses  and  functional  programming.  The  cycle  of 
each  process  is  specified  functionally.  One  can 
specify  timing  constraints  on  any  function,  and  thus 
also  on  any  step  of  processes  These  timing  con¬ 
straints  may  either  be  a  formula  l  iving  the  estimated 
time  of  a  step  or  formulae  giving  upper  and  lower 
bounds  on  the  estimated  time  of  a  step.  The  inter¬ 
preter  keeps  lower  and  upper  bound  total  time  es¬ 
timates  for  any  computation  path  it  follows. 
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According  to  Zave  and  others  who  have  used  PAIS- 
Ley,  PAISLey  is  intended  to  and  is  well-suited  to 
model  highly  parallel,  real-time,  possibly  distributed 
systems,  such  as  process-control  and  communication 
systems. 

Language  and  Specification 

A  PAISLey  system  is  a  fixed  set  of  processes,  each 
running  independently  and  asynchronously  with 
respect  to  the  others  of  the  set.  By  "fixed  number  of 
processes”  is  meant  that  the  number  of  processes  is 
determinable  at  specification  processing  time.  In  or¬ 
der  not  to  have  to  write  many  nearly  identical  copies 
of  a  definition  that  is  describing  the  behavior  of 
more  than  one  process,  a  process  specification  can 
be  replicated  over  an  indexed  set  of  processes,  but 
the  replication  is  a  kind  of  macro  obeyed  by  the 
specification  processor.  The  purpose  of  bounded¬ 
ness  in  the  number  of  processes  is  to  allow  proof 
that  synchronization  attempts  will  be  successful 
within  a  bounded  amount  of  time,  by  allowing  estab¬ 
lishing  bounds  on  the  mount  of  time  required  to  per¬ 
form  any  observable  function. 

Formally  a  system  is  specified  as  a  tuple  of  process 
cycle  functions,  each  applied  to  its  initial  state. 
Thus  to  specify  a  two-process  system,  consisting  of 
a  clock  whose  state  is  the  current  time  and  a  watcher 
whose  state  is  the  last  observed  time,  one  would 
write 

TIME=INTEGER;  clock-cycle: 

TIME  -->  TIME; 

watcher-cycle:  TIME 

-->  TIME;  (clock-cycle[0 J , 
watcher-cycle (01); 

A  process  is  specified  with  the  aid  of  a  cycle  func¬ 
tion  that  maps  the  process’s  state  to  its  next  state. 
Each  application  of  the  cycle  function  is  called  a 
process  step  or  a  process  cycle.  Because  the  argu¬ 
ment  to  a  process’s  cycle-function  is  only  the 
process’s  own  state,  each  process  appears  to  have  a 
non-forked,  deterministic  computation  tree.  How¬ 
ever,  processes  do  communicate  by  exchanging 
values  through  shared  synchronizing  channels.  That 
is,  a  process  may  have  to  wait  unspecifiable  num¬ 
bers  of  other  process’s  steps  before  it  can  continue 
its  own  step  with  an  unpredictable  value.  The  un¬ 
predictability  in  the  number  of  steps  and  in  the  value 
returned  from  the  exchange  causes  nondeterminism. 

In  PAISLey,  communication  between  two  processes 
occurs  with  the  help  of  exchange  functions.  Each 
exchange  function  name  specifies  both  the  type  of 
exchange  and  the  channel  over  which  the  exchange 
occurs.  For  example,  x-time  specifies  an  x  type 
exchange  over  the  time  channel.  When  two  proc¬ 
esses  have  called  an  exchange  over  the  same  channel 
at  the  same  time  (defined  more  precisely  below) 
then  the  function  calls  are  said  to  match,  and  each 


process  returns  as  the  value  of  the  function  call  the 
argument  of  the  other’s  call.  That  is,  if  process  n, 
calls  x-time  [11,  and  process  n2  calls 
x-t  ime  [ 2  ]  at  times  that  allow  the  calls  to  match, 
then  n,  returns  2  from  its  call  of  x-time,  and  n2 
returns  1  trom  its  call  of  x-t  ime.  To  each  process, 
an  exchange  function  call  appears  as  an  ordinary 
value-returning  function  call;  however,  during  the 
execution  of  the  exchange  function  call,  depending 
on  the  type  of  the  function,  a  process  may  have  to 
wait  asleep,  until  a  match  occurs  between  exchange 
function  calls  to  the  same  channel. 

The  three  types  of  exchange  functions  are  x  xr  and 
xm.  They  differ  by  whether  the  calling  process 
waits  or  not  and  with  what  other  kind  of  exchange 
calls  they  can  match.  Each  side  of  a  communication 
may  be  of  a  different  type. 

•  In  an  x-type  function,  the  caller  waits  if  there  is 
no  other  process  that  has  called  an  exchange 
function  over  the  same  channel.  If  and  when  a 
match  occurs,  the  call  returns  the  argument  of 
the  matching  call. 

•  In  an  xr-type  function,  the  caller  does  not  wait  if 
there  is  no  other  process  that  has  called  an  ex¬ 
change  function  over  the  same  channel;  in  this 
case,  the  call  returns  the  value  of  its  own  argu¬ 
ment.  If  there  is  another  exchange  call  to  the 
same  channel  waiting  or  issued  at  the  same  cy¬ 
cle,  the  a  match  occurs,  and  the  call  returns  the 
argument  of  the  matching  call. 

•  An  xm-type  function  call  behaves  as  an  x-lype 
function  call,  except  that  it  cannot  match  another 
xm-type  call  on  the  same  channel. 

fhus  x’s  can  match  x’s,  xr's,  and  xm’s.  xr’s  can 
match  x’s  and  xm’s,  but  xm’s  can  match  only  x’s 
and  xr’s. 

Any  time  an  exchange  function  is  evaluated,  if  more 
than  one  match  is  possible,  then  some  legal  match 
chosen  nondeterministically. 

Consider  the  following  PAISLey  definition,  of  a 
clock  ticking  every  second  and  a  watcher  occasion¬ 
ally  looking  at  the  current  time  of  the  clock.  The 
current  time  is  the  state  of  the  clock  and  the  last  time 
read  from  the  clock  is  the  state  of  the  watcher.  In 
PAISLey,  comments  are  surrounded  by  quotes. 

The  cycle  of  the  clock  process  can  be  described  in 
words  as:  compute  a  new  time  value  as  the  current 
time  plus  one  and  offer  the  current  time  value  to 
anyone  who  will  read  it.  The  new  time  value,  i.e., 
the  first  component  of  the  tuple,  is  taken  as  the  next 
state  of  the  clock.  The  offering  of  the  cun-ent  time  is 
accomplished  as  a  call  to  an  xr,  non-waiting  ex¬ 
change  function  on  the  time  channel  that  is  read  by 
the  watcher.  Since  the  clock  does  not  wait,  it  can 
guarantee  to  finish  its  cycle  in  precisely  one  second. 
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The  cycle  of  the  watcher  can  be  described  in  words 
as:  wait  until  there  is  a  current  time  being  offered  in 
the  time  channel;  when  the  match  occurs  take  the 
time  argument  passed  into  the  matching  call  and 
return  it  as  the  read  time.  Note  that  when  the 
watcher  gets  back  a  time,  and  that  time  is  installed 
as  the  next  state  of  the  watcher  that  time  will  be  one 
second  behind  the  time  installed  as  the  next  state  of 
the  clock. 

"BEGIN  DEFINITION" 

TIME=INTEGER ; 

"INITIAL  STATE  OF  PROCESSES"  “It  also 
says  that  the  system  has  two  processes,  the 
clock  and  the  watcher,  each  with  its  own  cycle." 

(clock-cycle [0 ] ,  watcher -cycle [  0  ] )  ; 

“DEFINITIONS  FOR  THE  CLOCK  PROCESS* 

"The  function  clock-cycle  takes  TIME  to  the 
next  TIME.  Thus,  the  state  of  the  clock  is  its 
current  time,  and  its  initial  state  0  is  time  0.* 

clock-cycle:  TIME  TIME; 

"The  lower  bound  and  upper  bound  of  the  time 
for  a  cycle  are  both  1.0  second.  Thus,  a  cycle 
is  precisely  1 .0  second  long!" 

clock-cycle:  !  lb  1.0  s,  ub  1.0  s; 

“The  next  time  is  the  first  component  of  a  two¬ 
tuple  consisting  of 

the  current  time  bumped  by  1 
and  an  offering  of  the  current  time  to 
the  watcher 

i.e.,  the  offering  is  done  only  for  effect  and  its 
results  are  ignored  in  the  clock’s  progression  to 
its  next  state." 

clock-cycle[time]  = 
proj [ (1, 

(sumt (time, 1) ]  , 
of fer-time [time] > 

)  I ; 

“offer-time  either  returns  with  the  time  it  offered, 
indicating  that  this  offered  time  was  not  read  or 
it  returns  null,  the  unique  value  of  type  FILLER, 
indicating  that  the  offered  time  was  read." 

offer-time:  TIME  -->  TIME  I  FILLER; 

"offer-time  is  defined  as  a  more  mnemonic 
name  for  a  exchange  function  of  type  xr  on  the 
channel  called  time,  i.e.,  for  xr-time.“ 

of fer-time l time]  =  xr-time[time] 

"It  is  important  that  the  exchange  function  for 
offer-time  not  get  hung  up  waiting  if  there  is  no 
other  process  who  has  asked  to  read  the  time 
from  the  time  channel;  if  the  clock  were  to  get 


hung  up,  the  clock  would  not  be  able  to 
guarantee  that  it  will  finish  an  execution  of 
clock-cycle  in  the  1.0  second  time  limit  set 
above;  thus  its  exchange  function  must  be  of 
type  xr." 

"xr-time  will  return  its  argument  if  no  other  proc¬ 
ess  has  asked  to  read  the  time  channel  and  null 
otherwise,  as  is  required  for  offer-time " 

"DEFINITIONS  FOR  THE  WATCHER 
PROCESS" 

"watcher-cycle  appears  to  take  a  TIME  to  some 
TIME,  but  in  fact,  it  ignores  the  input  TIME  and 
occasionally  returns  a  TIME  read  from  the  time 
channel." 

watcher-cycle:  TIME  -->  TIME; 
watcher-cycle [time]  = 

read- time [null ] ; 

read-time:  FILLER  ->  TIME; 

"read-time  is  a  mnemonic  for  a  waiting  ex¬ 
change  function,  i.e.,  of  type  x,  on  the  time 
channel;  x-time  will  wait  until  another  process 
has  attempted  an  exchange  on  the  same  chan¬ 
nel  and  will  return  the  argument  of  that  call. 
Since  the  only  other  process,  the  clock-cycle, 
will  be  calling  offer-time  every  second,  the 
watcher’s  x-time  will  wait  no  more  than  one  sec¬ 
ond  until  it  returns,  if  and  when  the  watcher 
does  a  call  to  x-time." 

read-time [null ]  =  x-t ime [ nul 1 ] ; 

"END  DEFINITION” 

Now  the  question  is  what  is  the  computational 
model  of  the  formal  model  of  PAISLey.  That  is, 
how  is  concurrency  modeled?  The  model  is  unusual 
in  that  there  are  definitely  sequences  of  states.  How¬ 
ever,  the  state  transitions  are  not  the  unit  of  inter¬ 
leaving.  Rather,  a  state  transition  is  defined  as  an 
application  of  a  function,  which  in  turn  may  be  de¬ 
fined  in  terms  of  other,  possibly  concurrent  function 
applications.  The  initiation  and  termination  of  func¬ 
tions  applications  that  are  the  units  of  interleaving. 

A  system  in  PAISLey  is  a  set  of  processes,  each 
running  independently  of  and  asynchronously  with 
each  other.  A  process  specification  describes  a  se¬ 
quence  of  states.  Each  process  has  an  initial  state 
and  each  subsequent  state  is  obtained  from  the  previ¬ 
ous  by  application  of  a  mapping  or  function  on 
states  to  states.  Each  application  of  a  process's  state 
transition  mapping  is  called  a  step  or  cycle  of  the 
process.  Figure  9(a)  shows  a  system  with  three 
processes.  In  the  absence  of  synchronization,  each 
process’s  cycles  proceed  independently  and  concur¬ 
rently  of  each  other.  Nothing  can  be  said  in  the 
formal  model  about  the  speeds  of  these  cycles.  In 
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the  absence  of  synchronization,  the  cycles  do  not 
occur  in  any  kind  of  lock-step  with  each  other. 
Thus,  the  figure  shows  the  cycles  taking  varying 
amounts  of  time  and  states  of  processes  not  lined  up 
with  each  other  in  time. 

An  event  is  either  an  initiation  or  a  termination  of  a 
mapping  application.  Thus  there  is  an  event  at  least 
at  the  beginning  and  end  of  each  step  of  any  process. 
There  may  be  more  events,  because  the  definition  of 
a  mapping  may  be  in  terms  of  other  mappings  or  of 
tuples  of  mappings.  The  initiation  and  termination 
of  each  of  these  submappings  is  an  event. 
Moreover,  the  individual  mappings  of  a  tuple  of 
mappings  are  evaluated  concurrently.  Therefore, 
within  each  cycle  of  a  process,  there  may  be  any 
number  of  mapping  evaluations  going  on  concur¬ 
rently,  with  their  starting  and  termination  events  oc¬ 
curring  in  any  which  order.  Figure  9(b)  shows  the 
detail  of  two  cycles  of  one  process.  Each  cycle  has 
an  encompassing  mapping  application.  Each  of 
these  contains  nested  mapping  applications,  some 
disjoint  and  some  overlapping  with  each  other.  The 
events  are  marked  with  little  filled  boxes. 

The  events  of  all  processes  of  a  system  are  inter¬ 
leaved.  Thus  the  smallest  observable  grain  of  com¬ 
puting  are  the  initiation  and  the  termination  of  a 
function  evaluation.  Within  each  process’s  cycle 
there  may  be  any  number  of  possibly  concurrent 
function  applications  going  on.  It  is  their  startings 
and  endings  that  are  interleaved.  If  two  events  are 
supposed  to  occur  at  precisely  the  same  time, 
whatever  that  means,  one  of  them  will  be  chosen 
arbitrarily  to  execute  first.  Thus,  in  Figure  9(b),  the 
two  events  on  the  same  vertical,  time  axis  near  the 
middle  of  the  second  cycle  are  arbitrarily  inter¬ 
leaved. 

The  author  of  this  module  asked  Zave  what  is  the 
model.  She  replied  by  electronic  mail  that  “It  is 
definitely  operational,  as  there  is  an  interpreter 
which  nondeterministically  selects  the  next  event  in 
the  computation.  Petri  nets  and  dataflow  diagrams 
both  capture  some  aspects  of  the  execution  model.” 

Tools 

As  PAISLey  is  an  executable  specification  language, 
there  is  an  environment  providing  a  specification 
checker  and  a  specification  simulator.  The  specifi¬ 
cation  checker  does  all  sorts  of  compile-time  checks 
including  that  all  functions  are  called  with  argu¬ 
ments  of  the  correct  type.  The  simulator  tool  is 
quite  spiffy  with  a  variety  instructions  to  allow  user 
to  select  more  or  less  output,  frequency  of  sampling, 
etc.  Also  the  output  is  always  pure  ascii  to  allow 
other  tools  to  be  used  to  analyze  the  output  in  the 
traditional  UNIX  pipe  paradigm. 

Performance  information  can  be  given  for  functions. 
One  can  specify  a  distribution  of  execution  times. 


lower  and  upper  bounds  on  the  execution  time,  or 
both.  The  simulator  will  keep  track  of  simulated 
time  elapsed,  using  a  random  number  generator  to 
select  some  time  in  the  range  if  a  range  is  given. 

The  PAISLey  processor  and  other  tools  are  available 
from  the  UNIX  tool  chest  and  is  available  free  to 
educational  institutions. 

Actual  Use 

PAISLey  has  been  used  in  projects  at  AT&T  as  an 
executable  specification  language  [Zave87c, 
Zave91J.  These  include  the  specification  of  the  in¬ 
terface  to  a  database  in  the  Submarine  Lightguide 
Project,  the  specification  of  the  user  interface  to  the 
PAISLey  environment,  and,  in  the  FEARS  (Finite 
Element  Adaptive  Research  Solver)  project,  the 
specification  of  a  distributed  implementation  of  an 
application  that  had  never  been  distributed  before. 
In  all  of  these  cases,  it  was  found  that  “a  little  for¬ 
malization  goes  a  long  way"  [Zave9i]  to  help  under¬ 
stand  difficult  problems.  This  understanding  comes 
from  the  mere  exercise  of  trying  to  formalize  the 
system  under  design  even  if  the  formalization  is  left 
incomplete. 

Other  Similar  Systems 

The  specification  language  Gist  [Feather87],  devel¬ 
oped  by  Feather  and  others  at  ISI,  is  in  a  family  with 
PAISLey,  although  its  formal  definition  is  probably 
more  carefully  laid  out.  In  Gist,  the  meaning  of  a 
concurrent  program  is  a  set  of  histories ,  each  being  a 
sequence  of  transitions.  A  transition  is  a  set  of 
deltas,  and  each  delta  is  a  function  on  a  primitive 
state  variable  to  its  next  value.  By  having  a  function 
for  each  variable  of  the  state,  concurrency  can  be 
represented  to  the  granularity  of  the  individual  vari¬ 
able  update.  Gist  is  used  to  write  specifications  for 
components  of  distributed  composite  systems,  from 
which  correct  implementations  of  tire  components 
and  of  the  system  itself  can  be  formally  derived. 

Another  operational  approach  based  on  sequences  of 
events  is  that  of  TSL-1  (Task  Sequencing 
Language- 1)  [Luckham86]  TSL-1  is  language  for 
specifying  sequences  of  tasking  events  that  occur 
during  the  computation  of  a  distributed  Ada  pro¬ 
gram.  The  events  of  interest  are  task  initiations  and 
terminations  and  rendezvous  initiation  and  termina¬ 
tion. 

TSL-1  statements  are  annotations  added  to  Ada  pro¬ 
gram  that  appear  as  comments  to  the  Ada  compiler, 
but  when  processed  by  the  TSL  compiler,  cause  gen¬ 
eration  of  calls  to  a  run-time  monitor  which  checks 
that  the  actual  computation  is  consistent  with  the 
annotations. 

TSL-1  statements  allow  specification  of  the  events 
that  will  occur  during  a  program's  computation;  it 
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also  allows  specification  of  when  two  of  these 
events  are  connected,  i.e,  that  one  must  follow  the 
other.  For  example,  the  acceptance  of  an  entry  call 
is  connected  to  and  must  always  follow  the  cor¬ 
responding  entry  call.  The  ordering  of  all  other  pairs 
of  events  must  be  left  unspecified  because  in  a  dis¬ 
tributed  system,  there  is  no  clear  notion  of  what  hap¬ 
pens  first.  Two  events  may  appear  in  opposite  or¬ 
ders  to  different  obso  vers  at  two  different  sites  in 
the  system.  The  specified  events  and  connections 
imply  a  partial  ordering  of  events.  The  checking 
done  by  the  run-time  monitor  is  that  the  actual 
events  in  the  monitored  computation  are  consistent 
with  this  partial  ordering. 

Because  TSL-1  is  formally  defined,  it  should  also  be 
possible  to  formally  verify  the  consistency  of  the 
specification  with  the  program,  and  not  have  to  rely 
on  mn-time  monitoring. 

8.  STATEMATE 

STATEMATE  [Harel88a,  Harel88bJ  is  a  graphics- 
based  environment  for  describing  reactive  concur¬ 
rent  systems.  The  mode  of  use  of  it  is  similar  to  that 
of  SARA,  described  above.  One  is  expected  to  use 
the  STATEMATE  Languages  to  carry  out  the  design 
of  a  system  starting  from  requirements.  In 
STATEMATE,  the  system  under  design  (SUD)  is 
described  with  three  different  views,  structural, 
functional,  and  behavioral.  As  with  SARA,  the  idea 
is  to  obtain  redundancy,  as  each  aspect  is  described 
from  three  different  points  of  view  and  these 
descriptions  are  reconciled  as  part  of  the  consistency 
checks  performed  by  the  STATEMATE  tools. 

The  structural  view  decomposes  the  SUD  into  its 
physical  components,  modules  together  with  chan¬ 
nels  for  the  flow  of  information.  The  functional 
view  describes  what  each  component  can  do,  i.e.,  the 
function  it  can  compute  or  the  data  it  can  carry.  The 
behavioral  view  describes  the  order  in  which  the 
components  are  activated  in  order  to  carry  out  their 
function. 

Language 

For  each  of  these  three  view,  STATEMATE  pro¬ 
vides  a  graphical  language  together  with  an  on-line 
graphics-based  editor  that  checks  the  validity  of  a 
diagram  as  it  is  being  built  element  by  element.  The 
resulting  diagrams,  called  module-charts,  activity- 
charts,  and  statecharts,  respectively  are  all  based  on 
a  number  of  new  graphical  conventions  invented  by 
the  authors  of  STATEMATE  to  get  around  the  size 
problems  that  other  graphic  notations  have  run  into 
and  which  prevent  them  from  being  used  on  large, 
real  systems. 

As  mentioned,  STATEMATE  was  designed  to  allow 
specification  of  large  and  complex  reactive  systems. 
A  reactive  system,  as  opposed  to  a  functional  trans¬ 


formational  system,  such  as  a  batch  formatter,  is 
event  driven  and  must  be  continually  available  to 
react  to  internal  and  external  stimuli.  Examples  in¬ 
clude  avionics  systems,  communication  networks, 
computer  operating  systems,  process  controllers, 
telephones,  VLSI  circuits,  windowing  systems, 
WYSIWYG  formatters,  etc.  The  problem  in  design¬ 
ing  such  systems  is  to  describe  their  behaviors 
clearly  and  realistically.  The  authors  of 
STATEMATE  have  paid  close  attention  to  the  prob¬ 
lems  of  visual  formalisms  in  designing  their  notation 
for  the  three  views.  They  were  quite  creative  in 
their  notation  for  the  behavioral  descriptions. 

To  give  more  detail  about  the  three  views. 

A  structure  chart  for  the  SUD  consists  of 

•  possibly  nested  modules,  each  being  a  rectangle, 

•  information  flows  from  modules  to  modules, 
each  being  a  possibly  multitailed  and  a  mul¬ 
tiheaded  arrow. 

The  SUD  is  itself  a  module,  and  modules  of  the 
environment  external  to  it  are  drawn  with  dashed 
lines.  Inside  the  SUD  module  are  both  processing 
modules  and  data  modules,  with  the  latter  being 
drawn  with  dashed  lines.  A  module  may  encap¬ 
sulate  internal  modules  which  are  shown  in  another 
diagram  in  which  the  encapsulating  module  is  regard 
as  the  SUD  of  that  diagram.  In  this  manner,  the 
structure  is  hierarchically  decomposed  into  modules 
that  have  no  internal  substructure  For  an  example, 
see  Figure  10. 

An  activity  chart  is  similar  to  a  structure  chart,  ex¬ 
cept  that  the  rectangles  denote  the  activities  or  func¬ 
tions  carried  out  by  the  system,  and  the  arrows 
denote  flows.  A  solid  arrow  denotes  data  flow  and  a 
dashed  arrow  denotes  control  flow.  For  an  example, 
see  Figure  11. 

The  behavior  charts  are  the  most  innovative.  They 
may  be  thought  of  as  extended  state  transition 
diagrams  (extended  finite-state  machine)  for  which 
the  traditional  limitations  of  these  diagrams  have 
been  avoided.  State  transition  diagrams  are  inappro¬ 
priate  for  describing  behavior  of  complex  reactive 
systems  because  they  are  flat  and  unstructured  and 
inherently  sequential.  Moreover,  they  tend  to  suffer 
an  explosive,  exponential  growth  in  the  number  of 
states  as  the  SUD  is  extended  slightly. 

These  problems  are  avoided  by  the  ability  to  hierar¬ 
chically  decompose  states  into  AND-  and  OR- 
combined  states  plus  a  broadcast  mechanism.  Once 
states  are  hierarchically  decomposed,  it  is  necessary 
to  be  able  to  have  transitions  enter  and  leave  at  any 
level  of  the  decomposition.  Figure  12(b)  shows  the 
diagram  resulting  from  OR-decomposition  of  Figure 
12(a).  Either  diagram  shows  that  from  state  V  the 
computation  goes  either  by  transition  e  to  state  S  or 
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by  transition  h  to  state  T  and  then  from  either  back 
to  Vby  transition  /.  Figure  12(b)  has  clustered  states 
5  and  T  into  a  new  state  U  such  that  to  be  in  U 
means  being  either  in  S  or  T.  If  it  turns  out  that  T  is 
specified  as  the  default  state  of  U,  then  the  diagram 
can  be  changed  to  that  of  Figure  12(c). 

Figure  13  shows  AND-decomposition.  In  Figure 
13(a),  there  is  a  cluster  of  ordered-pair  states.  If 
these  are  clustered  into  a  new  state  U  consisting  of  a 
Cartesian  product  of  smaller  state  transition 
diagrams,  the  diagram  can  be  simplified  con¬ 
siderably  into  that  shown  in  Figure  13(b).  Quite 
likely  the  meaning  of  the  individual  sub  state  transi¬ 
tion  diagrams  is  clearer  than  that  of  the  larger 
diagram  with  ordered-pair  states.  Recall  your  own 
experience  constructing  the  AND-  and  OR- 
combined  finite  state  machines  when  you  learned 
that  the  union  and  the  disjunction  of  finite  state  lan¬ 
guages  were  also  finite  state.  Figure  14  shows  the 
use  of  broadcasting.  In  this  machine,  each  state  is  a 
three-tuple.  When  the  computation  is  in  state 
(V,W,R)  and  event  m  occurs,  then  the  next  state  is 
(X,Y,P)  because  the  transition  under  m  from  R  to  P 
broadcasts  e,  causing  transitions  from  V  to  X  and 
from  Wto  Y. 

Concurrency  is  achieved  through  the  AND  decom¬ 
position  using  Cartesian  product  states.  Each  sub 
transition  diagram  can  be  considered  the  specifica¬ 
tion  of  an  independent  process  running  concurrently 
with  the  process  that  is  specified  by  the  other  sub 
transition  diagrams.  Thus  in  Figure  13(b),  one  proc¬ 
ess  is  running  the  diagram  in  S  and  the  other  is  run¬ 
ning  the  diagram  in  T.  In  figure  14,  there  are  three 
processes,  S,  T,  and  Q.  Synchronization  is  said  to 
occur  at  like  named  transitions  in  the  sub  transition 
diagrams.  Thus  in  Figure  13(b),  the  first  process 
that  gets  to  a  transition  e  will  have  to  wait  until  the 
other  gets  there  also  in  order  that  both  can  proceed. 


Pnueli  by  electronic  mail.  The  basic  idea  is  to  con¬ 
sider  the  atomic  transitions,  i.e.,  those  that  go  from 
atomic  states,  which  have  no  components.  “At  each 
step  in  the  execution  of  a  statechart,  there  is  a  set  of 
events  and  conditions  that  come  either  from  the  en¬ 
vironment,  or  have  been  generated  by  the  statechart 
in  the  immediately  previous  step.  These  events  and 
conditions  enable  a  certain  set  of  transitions,  which 
are  edges  in  the  statechart  graph  that  depart  from  a 
state  that  is  currently  active,  and  whose  labels  are 
statisfied  by  the  events  and  conditions  that  are  cur¬ 
rently  true.  The  next  step  consists  of  a  maximal 
conflict-free  set  of  enabled  transitions,  and  all  of 
them  are  jointly  taken  in  this  step.  In  case  of  non¬ 
determinism,  several  such  maximal  conflict-free  sets 
may  be  available.”  One  of  these  is  nondeterminis- 
tically  selected  and  all  of  its  transitions  are  take  in 
this  step.  “In  interactive  simulation,  the  user  is 
asked  to  choose  one.  In  non-interactive 

(batcb-)simulation,  the  system  chooses  one  at  ran¬ 
dom.  The  taken  transitions  usually  generate  events 
and  modify  conditions,  and  these  will  be  available  in 
the  construction  of  the  next  step." 

There  is  true  concurrency  in  the  formal  model,  as  for 
PAISLey.  However,  since  the  set  of  transitions  se¬ 
lected  to  fire  in  parallel  are  mutually  non¬ 

conflicting,  the  result  can  be  no  different  that  having 
gone  through  the  same  transitions  in  any  order. 
Thus,  the  model  is  equivalent  to  a  fully  atomic-step 
interleaving  model.  The  obvious  question  is  “Why 
is  there  this  unnecessary  concurrency  in  the  formal 
model?”  Perhaps,  it  is  to  justify  the  interpreter  tool 
using  the  same  model,  i.e.,  of  doing  many  steps  con¬ 
currently.  Certainly  time  estimates  will  be  more  ac¬ 
curate  if  the  concurrency  in  the  model  is  an  accurate 
reflection  of  the  concurrency  that  can  take  place  in 
real  life. 

Actual  Use 


The  ability  to  decompose  states  and  to  broadcast  are 
powerful  tools  for  reducing  the  size  of  transition 
diagrams  into  manageable  chunks,  each  part  of 
which  can  be  understood  independently  for  its  con¬ 
tribution  to  the  whole.  But  what  is  the  meaning  of  a 
computation  when  states  have  substructure.  If  a 
state  S  consists  of  a  subdiagram,  then  activation  of  S 
means  activation  of  the  subdiagram.  Then  suppose 

S,  at  the  level  it  appears  atomic,  is  concurrent  with 
state  T,  then  what  is  the  relationship  between  the 
components  of  S  with  7?  Moreover,  in  an  interleav¬ 
ing  model,  what  is  considered  atomic  is  critical,  for 
that  determines  the  grain  of  interleaving.  If  in  a 
nondeterministic  selection  S  is  selected  to  run  before 

T,  then  should  the  submachine  of  S  finish  entirely 
before  initiating  T  or  should  the  components  of  S  be 
interleaved  with  7? 

The  module  author  raised  this  question  with  the  au¬ 
thors  of  STATEMATE  and  received  an  answer  from 


STATEMATE  is  in  use  by  several  companies,  in¬ 
cluding  Israel  Aircraft  Industries  and  SEI  itself  to 
help  specify  and  design  reactive  systems.  Leveson 
and  others  report  on  the  use  of  STATEMATE  to 
build  a  system  requirements  specification  for  a  real 
aircraft  collision  avoidance  system,  a  system  involv¬ 
ing  real-time  concurrency  [Leveson9l  ]. 

Tools 

Among  the  STATEMATE  tools  are  the  following: 

•  a  simulation  package  for  executing  the  specifi¬ 
cation  of  the  SUD  to  allow  observation  of  its 
behavior 

•  report  generators  that,  among  other  things,  can 
generate  DoD  required  standard  documentation 

•  testing  package  for  doing  a  number  of  dynamic 
tests,  such  as  reachability  analysis  and  detection 
of  deadlock  and  nondeterminateness 
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•  an  Ada  code  generator  that  produces  an  Ada  pro¬ 
totype  of  the  SUD  according  to  simple  rules 
about  how  to  implement  the  components  of  a 
specification 

9.  Process  Algebras 

CCS  (Calculus  of  Concurrent  Systems)  and  CSP 
(Communicating  Sequential  Processes)  are  for¬ 
malisms  for  specifying  concurrent  systems  in  terms 
of  sets  of  possible  traces  of  observable  events  given 
rise  to  by  the  system.  Thus  the  formalisms  are  oper¬ 
ational.  Furthermore,  each  specifies  a  system  in 
terms  of  its  component  processes  that  are  independ¬ 
ent  except  for  explicit  communication  between 
them.  Each  component  is  specified  in  terms  of  con¬ 
straints  on  its  possible  traces  of  observable  events. 
The  system  as  a  whole  is  understood  as  a  composi¬ 
tion  of  these  traces  according  to  various  trace  com¬ 
position  operators. 

In  both,  each  process  is  specified  in  a  grammar-like 
notation  in  which  the  nonterminals  or  variables  are 
regarded  as  process  states  and  the  terminals  or  con¬ 
stants  are  regarded  as  names  of  actions,  events,  or 
transitions.  A  multiprocess  system  is  specified  by 
composing  process  definitions  using  a  variety  of 
operators  that  model  choice  between  processes  and 
concurrent  execution  of  processes.  These  operators 
form  a  process  algebra 

CCS  was  developed  as  a  formalism  for  describing 
multiprocess  systems  and  for  exploring  the  various 
notions  of  equivalence  of  processes 
[Milner80,Mi!ner89],  The  original  CSP  was  in  fact  a 
programming  language  [Hoare78]  that  later  proved 
to  be  the  inspiration  for  the  Occam  language.  A 
proof  system  for  that  version  of  CSP  can  be  found  in 
a  paper  by  Apt,  Francez,  and  de  Roever  [Apt80], 
The  CSP  formalism  (as  opposed  to  programming 
language),  developed  to  explore  specification  of 
processes,  is  described  in  a  book  of  the  same  title 
[Hoare85].  These  formalisms  have  been  the  inspira¬ 
tion  for  at  least  one  standardized  concurrent  system 
specification  language,  LOTOS  [IS089]  that  is  being 
used  to  specify  Open  Systems  Interconnection 
(OSI).  There  is  a  more  recent  extension  of  CCS 
called  SCCS  (Synchronous  CCS)  for  specifying  sets 
of  processes  that  operate  in  lock-step  synchronized 
concurrency  [Cohen86]. 

Language  and  Specification 

The  languages  of  CCS  and  CSP  are  built  on  the 
standard  notation  for  mathematics,  using  theusual 
logical,  set,  and  function  operators. 

In  both  (although  strictly  speaking,  CCS  does  not 
really  define  the  trace),  a  trace  is  a  finite  sequence  of 
symbols  representing  atomic,  indivisible  observable 
events  in  which  a  process  or  processes  have  partic¬ 
ipated  in  up  to  some  instant  of  time.  The  event 


symbols  are  uninterpreted  in  the  CCS  and  CSP  for¬ 
malisms,  but  can  be  chosen  to  be  mnemonic  of  a 
meaning  to  the  human  reader.  For  example,  the 
event  start  jimer  can  be  understood  as  the  event  of 
the  timer  starting  up,  even  though  to  CCS  and  CSP, 
it  is  no  more  than  just  another  atomic  event. 

Thus,  in  addition  to  the  logic,  set,  and  function 
operators  are  a  collection  of  operators  for  working 
with  finite  sequences  such  as  concatenation,  head, 
tail,  Ith  element,  etc. 

The  concept  of  observable  event  is  critical  and  pro¬ 
vides  a  powerful  abstraction  tool.  It  is  up  to  the 
defmer  of  a  system  to  specify  which  of  the  possible 
indivisible  actions  that  occur  during  the  execution  of 
the  system  are  considered  observable.  Events  not 
critical  to  the  abstract  description  of  the  system  can 
be  ignored.  Among  the  operators  of  CCS  and  CSP 
is  restriction  of  a  trace  to  symbols  in  a  sub-alphabet 
of  symbols. 

The  specification  of  a  sequential  program  is  given  as 
a  description  of  the  set  of  all  possible  traces  of  ob¬ 
servable  events  of  the  program.  The  specification  of 
a  concurrent  program  is  given  as  the  composition  of 
specifications  of  its  constituent  sequential  processes. 
This  composition  effects  an  interleaving  of  the 
events  of  the  individual  processes.  For  this  inter¬ 
leaving  to  be  meaningful  and  to  capture  all  possible 
computation  histories,  it  is  essential  that  the  events 
be  atomic.  Communication  between  two  processes 
is  accomplished  by  having  two  processes  execute 
two  separate  halves  of  what  is  considered  one  event. 
One  half  is  the  write  and  the  other  half  is  the  read  of 
a  datum  on  a  channel.  Both  processes  have  the  same 
event  symbol  in  their  traces.  The  process  that  ar¬ 
rives  at  its  half  of  the  event  first  must  wait  until  the 
other  arrives  at  the  other  half;  only  then  does  the 
event  happen,  i.e.,  the  reader  reads  what  is  written. 

Fundamental  Semantics 

In  both,  one  views  a  collection  of  process  definitions 
as  specifying  what  is  called  a  synchronization  tree. 
A  synchronization  tree,  shown  in  Figure  15,  is  not 
unlike  the  tree  of  possible  computations  of  an 
NDISM  illustrated  in  Figure  1 .  There  is  more  infor¬ 
mation  embodied  in  the  synchronization  tree,  but  it 
is  possible  to  derive  from  it  the  tree  of  possible  com¬ 
putations  of  the  NDISM  implied  by  the  synchroniza¬ 
tion  tree  and  its  process  definitions.  To  understand 
CCS,  CSP,  and  langauges  derived  from  them  it  is 
useful  to  understand  the  NDISM  implied  by  a  set  of 
process  definitions. 

Consider  Figure  15  as  a  representation  of  a  collec¬ 
tion  of  process  definitions.  Each  node  represents  a 
global  state  of  the  defined  processes  perhaps  ex¬ 
pressed  as  a  tuple  of  the  states  of  the  individual 
processes  if  it  is  desired  to  examine  the  composition 
of  the  states.  Each  arc  represents  a  transition  from 
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one  state  to  another  via  an  action  or  event  whose 
name  is  the  label  of  the  arc.  There  is  one  arc  label  x 
that  is  a  place  holder  naming  all  hidden  actions  A 
hidden  action  is  an  action  involving  portions  of  the 
state  that  are  not  intended,  for  the  purposes  of  the 
definition,  to  be  visible  to  the  user  of  the  system. 
All  other  labels  are  names  of  actions  that  the  user  of 
the  system  is  to  be  aware  of. 

One  can  take  either  an  active  or  an  inactive  view  of 
a  system.  In  the  active  view,  tire  viewer  is  a  user  is 
operating  the  system  and  non-x  labels  are  names  of 
actions  and  that  can  be  explicitly  chosen  or  invoked 
by  the  user,  while  x  labels  are  place  holders  for  inter¬ 
nal  actions  over  which  the  user  has  no  control  that 
cannot  be  invoked.  In  the  inactive  view,  the  viewer 
is  merely  watching  the  system  compute.  Non-x  la¬ 
bels  name  actions  that  are  intended  to  be  visible  to 
the  viewer,  while  x  labels  are  place  holders  for  inter¬ 
nal  actions  that  are  intended  to  be  invisible  to  the 
viewer. 

The  literature  on  CSP  and  CCS  takes  both  points  of 
view,  unfortunately  often  in  the  same  document. 
The  mixture  of  viewpoints  was  confusing  to  the  au¬ 
thor  of  this  module,  because  the  reasoning  consistent 
with  one  point  of  view  is  not  applicable  to  the  other. 
Moreover,  the  passive  view  of  just  observing  evnts 
happen  puts  the  viewer  in  the  awkward  position  of 
observing  unobservable  x  events.  Therefore,  this 
module  takes  solely  an  active  point  of  view. 

As  with  the  tree  of  possible  computations  of  an 
NDISM,  a  forking  node  of  a  synchronization  tree 
denotes  a  choice  of  different  actions  out  of  the  state 
represented  by  the  node.  If  the  labels  of  all  of  the 
arcs  coming  out  of  a  node  arc  distinct  and  none  of 
them  is  x,  then  the  node  is  said  to  be  choosable.  In 
this  circumstance  each  arc  has  a  unique  label  by 
which  it  can  be  selected  and  non  of  them  is  invisible. 
Otherwise,  if  at  least  two  arcs  are  labelled  the  same 
or  there  is  at  least  one  arc  labelled  X,  then  the  node  is 
said  to  be  nonchoosable.  The  meaning  of  being 
choosable  is  that  in  the  active  view,  the  external  en¬ 
vironment  can  choose  which  action  to  take  from  a 
state  simply  by  invoking  that  action’s  label.  If  two 
arcs  are  labelled  the  same,  choosing  that  label  does 
not  uniquely  identify  a  single  arc;  thus  the  choice 
must  be  made  internally.  If  at  least  one  arc  is 
labelled  x,  then  the  external  environment  looses  the 
ability  to  completely  choose  because  the  hidden 
events  denoted  by  the  x  labelled  arcs  might  happen 
before  the  external  environment  can  exercize  a 
choice  by  explicitly  invoking  a  non-x  label. 

The  idea  of  a  node  being  choosable  or  nonchoosable 
simply  does  not  jibe  with  a  passive  view.  It  is 
simply  impossible  to  passively  observe  whether  or 
not  an  active  choice  has  been  made  when  a  choice  is 
observed  The  set  of  possible  observable  events  is 
no  different  when  the  choice  is  purposeful  from 
when  it  is  noii 


In  the  literature  on  COS,  CSP,  and  their  linguistic 
descendants,  choosable  choices  are  called 
deterministic  and  nonchoosable  choices  are  called 
nondelerministic.  This  choice  of  vocabulary  to  de¬ 
scribe  different  choices  within  the  specified  system 
is  perhaps  unfortunate  because  of  die  entirely  differ¬ 
ent  meaning  of  these  terms  at  the  level  of  the  formal 
model  of  the  specified  system  At  the  level  of  the 
formal  model,  if  the  synchronization  tree  has  any 
forks,  the  specified  system  is  called  nondeterminis- 
tic,  and  a  de'ermimstic  system  is  one  whose 
synchronization  tree  has  no  forks,  i.e.,  at  any  state 
there  is  at  most  one  possible  action  out  of  the  state 
To  avoid  this  confusion,  this  module  continues  to 
use  the  terms  “choosable”  and  “nonchoosable”  for 
expressing  the  degree  of  external  control  over 
choices  in  a  nondeterministic  system,  which  has 
choices. 

Each  synchronization  tree  denotes  a  set  of  possible 
computations.  In  CCS  and  CSP  a  computation  is  a 
sequence  of  states  for  which  the  actions  between 
them  have  non-x  labels.  In  other  words,  the  ob¬ 
served  computations  consist  only  of  the  non-hidden 
actions  that  are  taken  in  traversing  die  synchroniza¬ 
tion  tree  from  the  root  towards  a  leaf.  Figure  16 
shows  the  set  of  computations  denoted  by  the 
synchronization  tree  of  Figure  15.  Some  are  infinite 
and  some  are  finite.  All  start  with  the  initial  state 
from  which  there  was  only  one  possible  action,  that 
labelled  a.  Observe  that  transitions  labelled  x  and 
the  node  at  their  target  are  eliminated  in  building  the 
computation  sequences.  Thus  a  computation  con¬ 
sists  only  of  actions  that  are  externally  visible  or 
invokable.  In  CSP,  a  computation  sequence  is  called 
a  trace. 


On  this  basis,  it  is  easy  to  see  how  to  construct  the 
tree  of  possible  computations  of  the  NDISM  implied 
by  a  synchronization  tree.  Figure  17  shows  the  ex¬ 
traction  of  the  tree  of  possible  computations  from 
the  synchronization  tree  of  Figure  15.  The  arcs  of 
the  synchronization  tree  are  dotted  lines  and  the  arcs 
of  the  tree  of  possible  computations  are  solid  lines. 
From  each  non-x  labelled  synchronization  tree  arc  is 
obtained  a  tree-of-possible-computations  arc  that  is 
labelled  identically.  If  the  parent  of  a  non-x  labelled 
synchronization  tree  arc  a  is  labelled  x,  then  the  cor¬ 
responding  arc  a  of  the  tree  of  possible  computations 
is  extended  upward  to  the  parent  of  the  arc  labelled 
x.  This  process  of  extending  arcs  upward  continues 
recursively  until  there  are  no  arcs  labelled  x.  Figure 
18  shows  the  tree  of  possible  computations  without 
the  distraction  of  the  synchronization  tree  from 
which  it  was  derived. 


The  two  formal  systems,  CCS  and  CSP,  differ  in  the 
ways  that  forking  nodes  of  synchronization  trees  can 
be  specified.  Each  has  a  slightly  different  set  of 
choice  composition  operators.  In  addition  there  arc 
slightly  different  operators  for  specifying  concur- 
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rency.  The  effect  of  these  operators  is  on  the  repre¬ 
sentation  of  the  states  as  a  function  of  the  compo¬ 
nent  process  states  and  on  the  actions  that  are  pos¬ 
sible  to  take  from  these. 

Notation 

Chciceless  Sequential  Processes 

The  notations  to  describe  the  individual  processes  in 
CCS  and  CSP  are  quite  similar  and  will  be  described 
together  before  continuing  on  the  description  of  each 
separately. 

The  specification  of  a  choiceless  sequential  process 
has  the  flavor  of  a  recursive,  grammatical  specifi¬ 
cation  of  the  finite  state  language  of  traces  whose 
alphabet  is  the  set  of  observable  event  names. 

For  example,  a  specification  of  a  vending  machine, 
VM,  that  repeatedly  accepts  one  coin  and  in  response 
to  the  coin  issues  a  chocolate  is 

VM=coin  choc. VM  (CCS) 

VM=(coin-t(choc~+VM))  (CSP) 

which  is  to  be  read  “The  VM  accepts  a  coin  and  then 
issues  a  choc  and  then  repeats  itself. 

The  set  of  traces  that  these  specifications  generate  is 

{<coin,choc>°°} 

i.e.,  the  singleton  set  containing  the  unbounded  se¬ 
quence  of  arbitrary  repetitions  of  coin,  choc. 

Figure  19  shows  the  infinite,  linear  synchronization 
tree  generated  by  these.  Collapsing  the  synchroniza¬ 
tion  by  cycling  at  the  first  recurrence  point  yields  the 
state  transition  diagram  of  Figure  20. 

In  general,  if  P  is  a  process  and  a  is  in  the  alphabet 
of  P,  then 

a.P  (CCS) 

(a-4P)  (CSP) 

describes  a  process  that  does  action  a  and  then  does 
the  actions  of  P. 

With  the  common  parts  of  the  two  notations  de¬ 
scribed,  consideration  turns  to  the  choice  and  con¬ 
currency  composition  operators  which  differ  in  the 
two  languages. 

Choices 

Both  notations  have  ways  to  express  both  choosablc 
and  nonchoosabie  choices.  Even  within  a  kind  of 
choice,  the  notations  differ  in  subtle  ways.  In  the 
following  discussions,  unless  otherwise  explicitly 
stated,  P,  Q,  R,  and  S  are  processes  and  a,  b,  c,  and  d 
are  actions,  which  are  assumed  to  be  in  the  common 
alphabets  of  the  processes  involved.  In  cases  in 
which  what  happens  when  an  action  is  not  in  the 
involved  processes'  alphabets,  the  alphabets  arc  de¬ 
scribed  explicitly. 


In  CCS,  all  choices,  choosablc  and  not  involve  die 
use  of  the  +  operator  on  processes 

P+Q  behaves  either  as  P  or  as  Q.  As  oon  as  the 
first  action  of  one  process  is  performed,  the  other 
pioeess  is  discarded. 

A  choosable  choice  is  one  in  which  the  labels  of  the 
first  actions  of  both  are  not  t  and  they  are  distinct, 
otherwise  the  choice  is  nonchoosabie.  Thus, 

a  P+b.Q 

is  choosable,  but 

a.P+a.Q, 
a  P+x.Q, 
x.P+b.Q, 
and 

x.P+x.Q 

are  nonchoosabie 

While  x  events  disappear  when  considering  com¬ 
putations,  they  cannot  always  be  elided  when  con¬ 
sidering  process  definitions.  Clearly, 

a.x.P=a.P 

and 

x.x.P =x.P , 
but  among 

A-aA+x.bA 

and 

D=a  B+b.B 

A  and  B  should  be  different.  B  may  perform  either  a 
or  b  in  any  state.  However,  A  may  reach  a  state  via  t 
in  which  b  is  possible  but  a  is  impossible  because 
the  other  option  has  been  discarded,  and  there  is  no 
way  for  the  environment  to  control  whether  or  not  A 
gets  to  this  state  Now  in  a  concurrent  combination 
of  processes,  the  environment  may  offer  only  an  in¬ 
vocation  of  a,  and  A  is  deadlocked.  If  the  the  envi¬ 
ronment  offers  only  an  invocation  of  a  tp  b,  there  is 
no  deadlock.  Figure  21  shows  the  state  transition 
diagrams  for  A  and  B 

In  CSP,  there  is  no  explicit  x  action  Therefore,  the 
distinction  between  choosable  and  nonchoosabie 
choices  must  be  made  explicit  in  the  operator 

(a-*P\b->Q),  where  a*b,  describes  a  process  which 
initially  does  one  of  a  or  b.  if  the  chosen  action  is  a, 
then  after  that  it  behaves  as  P.  If  the  chosen  action 
is  b,  then  after  that  it  behaves  as  Q 

The  T  operator  is  not  a  process  operator  even 
though  its  operands  arc  processes.  So,  in  CSP,  one 
cannot  say  "P\Q".  Its  operands  must  be  of  the  form 
“ action-tprocess "  so  that  there  is  always  an  explicit 
way  to  choose  the  desired  choice,  by  selecting  its 
first  action  Indeed,  the  “f  itself  is  not  really  the 
operator;  |  is  the  operator 

taking  for  operands  of  types  action,  process,  action. 
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and  process,  in  that  order.  The  expression 
(a->P\b-*Q)  is  considered  as  a  whole  much  the 
same  way  that  there  are  no  “if’,  “then",  and  “else" 
operators,  and  a  conditional  expression  is  considered 
as  a  whole.  Multiway  choices  are  written  as  flat 
expressions  using  one  pair  of  parentheses  and  more 
than  one  “1”.  Thus,  (a-»P|b-r£)|c->/?)  is  correct 
and  (a->P[(b->Q\c-*R))  is  not.  Note  also  the  re¬ 
quirement  that  the  initial  actions  of  each  operand  of 
“( •  •  •  ->  •  |  •  ••  -  )”  be  distinct  is  syntactic. 

It  is  syntactically  incorrect  to  write  (a-+P\a->Q) 

Indeed,  these  syntactic  constraints  are  what  distin¬ 
guish  CSP’s 

(a-»P|h~>0 
from  CCS’s 
a.P+b.Q 

purposely  written  without  parentheses,  which  means 
almost  the  same  thing.  The  CCS  “+”  is  an  operator 
that  can  be  applied  to  processes;  so  P+Q  is 
legitimate.  Also  it  is  legitimate  and  meaningful  to 
write  a.P+a.Q.  The  result  is  a  nonchoosable 
choice;  the  fact  that  the  first  actions  of  both 
operands  are  the  same  prevents  the  user  from  ex¬ 
ercizing  a  choice  that  chooses  between  a.P  and  a.Q. 

A  nonchoosable  choice  is  expressed  in  CSP  with  an 
operator  on  processes. 

PUQ  is  a  process  which  behaves  either  as  P  or  as 
Q.  The  choice  is  made  arbitrarily  without  knowl¬ 
edge  or  control  of  the  environment. 

The  other  way  to  obtain  a  choosable  choice  in  CSP 
is  with  a  genuine  operator  oil  processes 

P  [J  Q  is  a  process  which  behaves  either  as  P  or  as  Q. 
The  environment  can  control  which  of  P  or  Q  is 
selected  provided  that  the  control  is  exercized  on  the 
very  first  action. 

It  is  clear  that  if  a*b, 

(n->P)  D  <*— »<2) » (a-*P ! b-*Q) , 
but 

(a->P)Q(a->Q)*(a-+P)P(a-*Q) , 
which  in  turn  equals 
a~>(P[l0. 

With  the  choice  operators  it  is  possible  to  define 
more  realistic  vending  machines.  In  CSP,  a  vending 
machine  that  issues  a  chocolate  for  a  dime  and 
caramel  for  a  nickel  would  be  specified  as 

VM- 

((dime->(choc->VM))\ 

( nickel-^(caramel-*VM )))) . 

A  vending  machine  that  issues  either  a  chocolate  or 


a  cannel  for  each  coin,  but  the  customer  cannot 
predict  v  hich,  would  be  specified  as 

VM=(coin->( 

(choc->VM)P 
(caramet->VM) J) . 

In  CCS,  the  former  would  be  specified  as 
VM= 

((dime. choc. VM)+ 

(nickel.caTamel.VM)) , 

and  the  latter  would  be  specified  as 

VM=(coin.( 

(choc.VM)  + 

( caramel. VM ))) . 

Figure  22  shows  the  state  transition  diagrams  of  the 
two  newer  vending  machines. 

Concurrency 

In  both  CCS  and  CSP,  concurrency  is  introduced  by 
operators  that  cause  the  individual  actions  of  the  ar¬ 
gument  processes  to  be  interleaved  in  some  way  par¬ 
ticular  to  the  operator.  For  some  of  the  operators, 
there  is  the  possibility  of  synchronization  occurring, 
that  is,  of  two  processes  engaging  in  simultaneous 
complementing  actions.  These  complementing  ac¬ 
tions  are  considered  a  communication  (the  “S"es  in 
“CCS"  and  “CSP”!) 

In  CCS,  there  is  one  concurrency  operators  on  proc¬ 
esses  of  like  alphabet,  the  “f  operator.  Before  it  can 
be  defined,  it  is  necessary  to  define  complementing 
action  labels.  Two  action  labels  are  complementing 
if  they  have  the  same  spelling  but  one  has  a  over  bar 
and  the  other  does  not.  For  example  a  and  a  are 
complementing  labels. 

P\Q  is  that  process  whose  actions  are  the  interleaved 
actions  of  P  and  Q.  In  each  state,  any  action  from 
either  process  is  nondeterministically  chosen  to  the 
be  the  next  action  of  P\Q.  The  component  process 
whose  action  is  selected  is  taken  to  the  state  that 
follows  the  selected  actions.  If,  in  both  processes 
the  next  possible  actions  are  complementing,  then 
one  possible  next  action  is  the  t  action  which  takes 
each  component  process  into  the  state  that  follows 
its  one  of  the  complementing  actions. 

If  complementing  actions  are  possible,  it  is  possible 
for  the  composed  process  to  select  one  of  the  com¬ 
plementing  actions  to  take  as  an  individual  action. 

Given  process  definitions, 

A=aA' 

A’=cA 

and 

B=c.B' 

3'=T>.E 
That  is. 
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A=a.cA 

and 

B=c.5,fl. 

A\B  is  definable  as 

<A\B>=a.<A'\B> 

<A\B>=c.<A\B'> 

<A'iB>=c.<A'\B'> 

<A'\B>  =  c.<A\B> 

<A'IB> =x.<AIB'>  (here,  x = cc  ) 
<A\B'>=d.<A\B> 

<AlB'>=a.<A’lB'> 

<A'\B'>=d.<A'\B> 

<A'\B'>-c  .<A\B'> , 

where  <P\Q>  denotes  the  state  of  process  A\B  built 
from  state  P  of  process  A  and  state  Q  of  process  B. 
Figure  23  shows  the  state  transition  diagrams  of  A, 
B ,  and  A\B. 

In  CSP,  there  are  a  variety  of  operators  affecting  a 
concurrent  composition  of  processes.  Only  the  two 
main  ones  are  discussed  here.  The  distinction  be¬ 
tween  the  operators  is  in  their  treatment  of  potential 
interaction.  Recall  that  in  CCS,  an  interaction  might 
occur  when  two  processes  are  composed  and  they 
have  complementing  actions.  If  the  interaction  oc¬ 
curs,  the  two  complementing  actions  occur  and  can¬ 
cel  each  other  to  yield  a  single  x  action  that  is  invis¬ 
ible  to  the  observer.  Then  again,  the  interaction 
might  not  occur  and  each  complementing  action  is 
left  to  occur  on  its  own,  possibly  to  interact  with 
another,  external  complementing  action. 

In  CSP,  the  complementing  actions  are  either  like- 
named  events  or  an  input  and  an  output  on  the  same 
channel.  Thus  action  a  on  one  process  complements 
action  a  on  another  process.  An  output  of  a  value  v 
on  channel  c  is  written 

c!v . 

This  output  is  complemented  by  an  input  to  a  vari¬ 
able  x  from  the  same  channel  c,  which  is  written 

C?Jt. 

If  and  when  the  input-output  interaction  occurs  over 
channel  c,  the  result  is  that  the  value  v  is  assigned  to 
the  variable  x  of  the  reading  process's  context. 

The  simplest  concurrent  composition  operator  is  the 
parallel  composition  operator  “11”. 

If  P  and  Q  have  the  same  alphabet,  then  P\\Q 
denotes  the  process  with  that  same  alphabet  which 
behaves  as  the  system  composed  of  P  and  Q  inter¬ 
acting  in  lock-step  synchronization. 

That  is,  in  each  step  of  P\\Q,  if  the  next  actions  of  P 
and  Q  are  complementing,  then  the  common  event 
or  the  input  and  output  over  the  common  channel 
happens  and  each  process  is  taken  to  its  next  slate 


via  the  event  or  input  or  output.  If  the  next  actioas 
of  P  and  Q  are  not  complementing,  i.e  ,  they  differ 
or  are  not  over  the  same  channel,  then  the  processes 
deadlock. 

(a->P)li(a-*Q) =a->(PIIQ) 
(c!v^P)||<c?x^0x))=c<v-»(P||Q<v)) 

In  the  latter,  the  combined  event  is  considered  the 
output  to  the  external  environment. 

If  a*b  and  c*d,  then 

(a->P)||<b->0= 

(a-»P)li(c!v-»0  = 

(a->P)||(c?x->(20c))  = 

(cr.v-*P)\\(d?x~>Q(x)) = STOP 

Thus,  for  two  processes  with  identical  alphabets  to 
compose  in  parallel  without  deadlock,  they  must  go 
through  sequences  of  identical  actions  or  input  and 
output  over  identical  channels. 

If  however,  the  alphabets  of  the  processes  P  and  Q 
are  different,  then  events  that  happen  to  be  in  both  of 
their  alphabets  require  simultaneous  participation  of 
both  processes.  However,  an  event  that  is  in  the 
alphabet  of  one  and  not  the  other  is  ignored  by  the 
other  and  is  done  at  the  one's  leisure.  The  result  is 
that  the  alphabet  of  P\\Q  is  the  union  of  the  alphabets 
of  P  and  Q. 

Suppose  that 

a  is  in  the  alphabet  of  P  but  not  in  that  of  Q. 
b  is  in  the  alphabet  of  Q  but  not  in  that  of  P. 
c  and  d  are  in  both  alphabets,  and  c*d. 

Clearly  a*b.  Then  only  P  can  do  a,  only  Q  can  do  b, 
but  P  and  Q  must  do  c  or  d  simultaneously  for  P\\Q 
to  avoid  deadlock.  More  formally, 

(c->P)||(c->0=c-»<P|!0 
(c->P)||(d-»0 = STOP 
(a-»P)H(e->0=a-»(P||(c->0) 

(c->P)||<£>->0 = b-*«c->P)||0 
(a->P)||(h->0 = a-KP||(h->0)| 
b-K(a_>P)j|0  • 

Actions  in  the  common  alphabet  of  P  and  Q  require 
simultaneous  participation  of  both  processes,  while 
all  remaining  actions  occur  in  arbitrary  interleaving. 
To  see  this,  consider  the  processes  P  and  Q  defined 

P=a->h->c->P 
Q=d-*c-*Q . 

The  traces  of  P  and  Q  are  shown  in  Figure  24.  Also 
in  that  figure  is  a  representation  of  all  possible  traces 
of  P||0  Events  that  lie  in  a  chain  of  arcs  must  be 
ordered  as  in  the  chain,  but  events  that  lie  on  op¬ 
posite  paths  of  parallel  chain  of  arcs  are  not  ordered 
with  respect  to  each  other.  The  merging  of  the  event 
arcs  for  c  is  supposed  to  indicate  a  requirement  of 
simultaneous  occurrence.  Thus,  one  possible  trace 
is  a;d;h;c;d;a;h;c; .... 
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Note  that  if  P’s  and  Q’s  alphabets  have  no  actions  in 
common,  then  P  and  Q  are  completely  independent, 
and  the  traces  of  P\\Q  consists  of  arbitrary  interleav¬ 
ings  of  the  individual  actions  of  P  and  Q.  Each  such 
trace  is  indistinguishable  in  net  effect  from  even  a 
sequential  composition. 

Parallel  composition  interacts  with  choices  in  an  in¬ 
teresting  way.  Each  operand  process  is  considered 
to  be  in  the  other’s  external  environment.  Thus,  in 
any  step,  when  one  or  both  processes  offer  choos- 
able  choices  of  initial  events,  only  the  complement¬ 
ing  events,  if  any,  are  possible.  Each  process  is,  in 
effect,  choosing  the  other’s  choosable  choices  and  is 
choosing  the  right  one  to  continue  the  computation. 
Thus,  if 

P = (a-*b-*P\b—>P) 

Q=(a-*(b-*Q\c->Q)) 

then, 

PWQ = a-4<fr->P||(h~>0lc-*0) = a~»(h-»(P||0) 

In  the  first  step,  Q’s  first  action  chooses  the  a  choice 
of  P,  and  in  the  second  step,  the  b->P  chooses  the  b 
choice  of  (b->Q\c-+Q).  However,  letting  P\\Q  be  X, 

X=a^>(b->X) 

Note  however,  if  any  choice  is  nonchoosable,  the 
possibility  exists  that  the  internal  action  chooses  a 
first  action  not  complementing  the  only  or  chosen 
action  of  the  choosable  choices,  yielding  a  deadlock. 
As  mentioned,  the  traces  generated  from  PnQ  and 
P  0  Q  cannot  distinguish  them.  However  it  is  pos¬ 
sible  to  put  them  in  a  parallel  combination  with 
other  processes  so  that  P\~\Q  can  deadlock,  but 
PWQ  cannot.  Let  P = (a—>P)  and  Q  =  (b^Q)  where 
atb.  For  (P[lQ)\\P,  at  every  state,  the  lone  P  offers 
a;  therefore  P\\Q  is  forced  to  choose  the  P  alter¬ 
native  because  its  first  action  is  a.  However,  if 
P\\Q  is  put  into  a  concurrent  combination  with  P,  at 
every  state  the  lone  P  offers  a;  however,  the  P\AQ 
may  choose  internally  to  select  the  Q  alternative, 
whose  first  action  requires  b  to  proceed.  There  is  no 
b  coming  from  the  other  process,  so  the  combination 
deadlocks. 

The  other  main  concurrency  operator  is  the  inter¬ 
leave  operator  “III”  defined  for  processes  with  iden¬ 
tical  alphabets.  This  operator  gets  the  two  processes 
to  execute  concurrently  with  out  direct  interaction  or 
synchronization. 

An  action  of  PIIIQ  is  an  action  of  P  or  of  Q\  if  both 
processes  are  able  to  execute  the  same  action,  then 
only  one  is  chosen  nondeterministically  to  do  that 
action,  leaving  it  still  to  be  done  by  the  other. 

Thus, 

(a->P)lll(fc-><2)= 

a-^fPIIKfo— ><2))  0  >P)1II<2) 


If  a=b  then  effectively,  the  “III"  becomes  *f?’,  i.e., 
the  choice  becomes  nonchoosable.  In  general  the 
choice  is  choosable  in  that  if  a  and  b  are  different, 
choosing  the  first  action  determines  which  operand 
is  executed.  This  point  is  illustrated  best  when  a 
process  is  interleaved  with  another  copy  of  itself 
Let  R=(a-*b->R).  We  would  expect  that  R\\\R  be 
an  arbitrary  interleaving  of  a  and  b  events  such  that 
the  difference  in  the  numbers  of  os  and  bs  does  not 
grow  without  bound. 

R\UR= 

a-»((h-»/?)IHP) 
l#  a -MR  III  (b  -4  R))] . 

Since  the  first  actions  are  the  same  for  each  choice, 
this 

=  a->(«h-4tf)IIU?)  ri(/?HKh->/f))) 
which 

However, 

{b^R)\\\R= (a->((b->R)mb->R)))  Q  (h-»(PIIIP)) 

which 

=<a-»(h->((h-4«)lll/?)))0 
(h — >(o — K(h — ►/?)IIIP))) . 

Letting  (b->R)\HR  be  X,  we  have  that 

X=(a->b->X)  Q  (b->a->X) ,  and 

letting  Rlll/f  be  K,  we  have  that 

Y=(a->b->Y)D(b->a->X). 

CSP  has  a  number  of  other  operators  for  combining 
processes  in  concurrent  and  non-concurrent  be¬ 
havior.  These  include  operators  for 

•  piping  the  output  of  the  first  concurrent  process 
to  the  input  of  the  second, 

•  subordinating  the  second  process  to  the  first, 

•  executing  the  two  processes  sequentially, 

•  interrupting  the  first  process  with  the  second,  and 

•  alternating  between  the  two  processes  step-by- 
step. 


Observe  that  CCS’s  concurrency  operator,  is  dif¬ 
ferent  from  both  of  CSP’s  concurrency  operators, 
“II”  and  “111".  The  allows  both  synchronization 
and  interleaving,  and  which  one  it  does  at  any  time 
is  nondeterministic.  In  CCS, 


(a.P)\(b.Q) -a.(PHb  ^ )+b.((a.P)\Q ) 
(a.P)\(a.Q)=a.(.P\(a.Q))+a.((a.P)\Q) 
(a.P)\(a.Q)=UP\QHa.(P\{a.Q))+aX(a.P)\Q). 


This  is  different  from  in  CSP  in  which  applying  a 
synchronization  is  not  optional.  In  CSP, 
synchronization  is  obligatory  with  and  if  it  can¬ 
not  occur,  then  deadlock  happens.  Thus, 

(a-*P)\\(b-+Q)  is  a  deadlock 


while 
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(a ->P)ll(a ->Q)=a->(PHQ) . 

On  the  other  hand,  in  CSP  interleaving  is  obligatory 
with  “III”.  Thus, 

(a->P)\\\(b^>Q)  = 
a-»(Pi!l(h->0) 

(]h-*(a->P)IH0 

The  CCS  concurrency  operator  is  a  catch-all,  captur¬ 
ing  all  inodes  of  concurrency,  while  CSP  gives  a 
separate  operator  to  each  kind  of  concurrency. 
Similarly,  CCS  choice  operator  captures  all  kinds  of 
choice,  while  CSP  gives  a  separate  operator  for  each 
kind  of  choice. 

Prevention  and  Concealment  of  Actions 

CCS  has  an  operator  “\”  on  processes  and  sets  of 
actions  whose  effect  is  to  prevent  the  process  from 
doing  any  action  in  the  set. 

P\A  where  A  is  a  set  of  actions  is  that  process  ob¬ 
tained  from  P  by  preventing  P  from  doing  any  ac¬ 
tion  in  A. 

Thus, 

(a.P)\{a}  =NIL 

is  a  deadlock  because  its  only  possible  first  step  is 
prevented.  The  "\"  operator  can  be  used  to  cause  a 
CCS  parallel  composition  to  behave  like  a  CSP 
parallel  composition.  Recall  that 

(a.P)\(a  Q) = z.(P\Q)+a.(P](a.Q))+a.((a.P)\Q) . 

Preventing  the  individual  a  and  a  actions  forces  their 
cancellation  into  the  hidden  x  event. 

(la.P)\(a.Q))\(a)~x.(,P\Q) , 

thus  simulating  the  effect  of  CSP’s  ((a-»P)||(a-»0). 

CSP  has  an  operator  “\”  on  processes  and  sets  of 
actions  whose  effect  is  to  hide  as  internal  actions  the 
actions  of  the  process  that  are  in  the  set. 

PSA  where  A  is  a  set  of  actions  is  that  process  ob¬ 
tained  from  P  by  making  ail  actions  in  A  hidden, 
internal  actions. 

Thus, 

(a~»P)\{«}  =P\{a)  . 

Concealment  of  events  can  turn  a  choosable  choice 
into  a  nonchoosable  choice  by  hiding  the  actions  by 
which  the  choice  would  be  chosen. 

(a-*Pm-*Q)\[a,b)=PS{a,b)nQ\{a,b) 

CSP’s  “\”  operator  can  be  used  to  achieve  CCS’s 
hiding  of  cancelling  events  as  x  actions.  Suppose 
C=  {dvlve  alphabet  of  channel  c}.  Then, 

((c!v-yP)H(c?x->Q(x)))\C=  (PllQ(v))\C . 


CCS  does  not  need  a  concealment  operator  because 
it  is  implicit  in  the  cancelation  of  complementing 
events.  CSP  does  not  need  a  prevention  operator 
because  it  can  be  forced  by  using  its  obligatory 
synchronization  operator  together  with  processes 
whose  first  actions  are  disjoint. 

Example  Specification  in  CSP 

The  system  consisting  of  the  PRODUCER  and 
CONSUMER  running  concurrently  is 

SYSTEM=PRODUCER\\CONSUMER . 

The  definition  of  PRODUCER  would  be  something 
like 

PRODUCER= 

[produce  j/alue-* 

( c!value->PRODUCER )) , 

and  the  definition  of  CONSUMER  would  be  some¬ 
thing  like 

CONSUMER = 

( clvar ^(consume  contents_of_var 
-* CONSUMER )) . 

Verification 

Hoare's  book  on  CSP,  besides  being  a  text  book, 
treats  CSP  as  a  formal  system  and  gives  algebraic 
laws  that  can  be  used  to  show  that  two  specifications 
are  equivalent  and  to  prove  other  properties  such  as 
avoidance  of  deadlock.  Indeed  as  an  example  of  the 
power  of  the  system,  the  book  devotes  considerable 
space  to  specification  of  a  solution  to  the  dining 
philosophers  problem  and  verification  of  properties 
of  this  solution. 

Actual  Use 

CSP  has  been  used  to  specify  a  variety  of  systems. 
For  example.  Woodcock  has  used  CSP  to  specify 
and  prove  properties  of  several  different  primitives 
for  transaction  processing  [Woodcock87], 

The  module  author  has  even  seen  students  use  it 
informally  during  the  course  of  an  informal  discus¬ 
sion  of  how  a  certain  system  works.  This  fact  tes¬ 
tifies  to  the  naturalness  of  the  notation  and  the  case 
with  which  it  is  used.  Probably  its  greatest  strength 
is  the  uninterpreted  alphabet  that  allows  events  to  be 
considered  at  any  level  of  detail. 

Also  in  a  recent  study  at  SEI  comparing  several 
methods.  CSP,  VDM,  and  denotational  semantics 
[Place90],  to  specify  concurrent  software,  CSP  was 
taken  as  the  first  one  in  which  to  write  the  specifi¬ 
cation.  While  the  authors  of  the  report  professed  to 
being  fair,  it  seems  clear  in  retrospect  that  CSP  was 
chosen  to  be  first  because  working  with  it  involves 
less  notational  baggage  than  other  methods;  one  can 
write  strictly  the  relevant  events. 
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Tools 

At  least  two  tools  for  writing  and  verifying  CSP 
specifications  have  been  developed.  Both  use  the 
trace  model  of  L  SP-specified  computations  as  the 
basis  for  the  formalization  embodied  in  the  tool.  In 
one  case,  Moore  has  shown  how  to  carry  out  mul¬ 
tilevel  decompositions  of  requirements  not  unlike 
those  done  for  the  FDM  and  the  HDM  (See  Sections 
VI.2  and  VIA)  [Moore90].  He  uses  the  EHDM  (See 
Section  VI.4  on  HDM)  verification  system  to  verify 
proofs  of  the  correctness  of  the  decomposition,  so 
that  properties  ascribed  to  the  highest  level  can  be 
inferred  of  the  lowest  level.  Camilleri  has 
mechanized  the  CSP  trace  model  with  in  Higher  Or¬ 
der  Logic  (HOL)  so  that  the  HOL  verifyer  can  be 
used  to  prove  properties  of  a  CSP  specification 
[Camilleri90]. 

The  Concurrency  Workbench  is  an  automated  tool 
for  analyzing  networks  of  finite-state  processes 
specified  in  CCS  [Cleaveland89], 

Differences  Between  CCS  and  CSP 

The  two  languages  CCS  and  CSP  clearly  have  a  lot 
of  semantics  in  common,  and  their  operators  are  tan- 
talizingly  similar,  but  fundamentally  different.  Cor¬ 
respondences  are  shown  in  Table  1.  As  can  be  seen, 
except  for  the  exact  correspondence  between  CCS’s 
and  CSP's  no  CCS  operator  corresponds  to 
exactly  one  CSP  operator  and  vice  versa. 

It  seems  in  retrospect,  that  CCS  is  a  minimal  lan¬ 
guage  providing  no  concept  in  more  than  one  oper¬ 
ator  and  even  lumping  several  concepts  into  one  op¬ 
erator.  CSP  provides  more  specialized  operators 
each  providing  only  one  concept  and,  in  some  cases, 
more  than  one  way  to  achieve  a  single  concept.  For 
this  reason,  CSP  is  probably  more  useable  in  writing 
specifications  of  concurrent  systems.  Indeed,  one 
system  specification  language,  LOTOS,  which  is 
claimed  to  be  derived  from  CCS  first  and  CSP  sec¬ 
ond,  appears  to  be  more  a  descendent  of  CSP  than 
otherwise. 

Synchronous  CCS 

SCCS  (Synchronous  CCS),  also  devised  by  Milner 
[Cohen86],  is  an  extension  of  CCS  in  which  a  sys¬ 
tem  is  viewed  as  a  collection  of  processes,  all  run¬ 
ning  in  parallel  rather  than  being  interleaved  in  a 
nondeterministic  fashion.  That  is,  at  each  step,  each 
process  is  put  through  one  of  its  next  actions,  there 
being  the  possibility  of  choice  of  next  action  for  a 
process.  Each  process  is  specified  to  have  sequen¬ 
tial  behavior  with  choosable  or  non-choosable 
choices  at  any  step  just  as  in  CCS.  The  parallel 
composition  operator  gets  the  individual  processes 
working  together  in  lock-step  synchrony,  Thus  in 
SCCS,  a  system's  state  is  a  tuple  of  individual  proc¬ 
ess  states,  and  each  process  is  specified  by  equations 
much  as  in  CCS. 


Synchronization  or  communication  happens  when 
the  involved  processes  do  complementing  actions  in 
the  same  step.  It  is  possible  for  more  than  two  proc¬ 
esses  to  be  involved  in  a  synchronization  or  commu¬ 
nication,  because  all  processes  are  executing  in  all 
steps. 

In  order  to  permit  processes  to  act  at  different,  vary¬ 
ing,  and  unspecified  speeds,  the  definer  of  a  process 
can  introduce  choices  of  t  actions  at  any  point  to 
allow  the  other  processes  to  proceed  faster  with 
non-x  actions.  Of  course,  it  is  possible  to  split 
lengthy  actions  into  sequences  of  shorter  subactions; 
the  length  of  the  sequence  for  each  split  action 
would  be  made  proportional  to  an  estimated  time  for 
the  action.  Care  should  be  taken  in  decomposing 
actions,  for  it  is  intended  in  SCCS  that  process  ac¬ 
tions  be  atomic  and  non-interruptable. 

Milner  was  able  to  derive  CCS  from  SCCS.  Basi¬ 
cally,  given  an  SCCS  definition,  allow  each  process 
to  nondeterministically  choose  a  t  action  at  each 
steop.  Then,  in  any  computation,  in  each  step,  have 
all  processes  but  the  one  that  CCS  would  choose 
execute  x  actions.  The  result  is  a  CCS  interleaved 
computation.  Moreover,  SCCS  can  express  commu¬ 
nications  involving  more  than  two  processes;  doing 
so  is  impossible  in  CCS.  Therefore,  SCCS  is  strictly 
more  general  than  CCS. 

LOTOS 

LOTOS  (Language  Of  Temporal  Ordering 
Specification)  [IS089,Bolognesi87]  is  a  language  de¬ 
veloped  under  the  auspices  of  ISO  (International 
Standards  Organization)  to  allow  formal  specifica¬ 
tion  of  OS1  (Open  Systems  Interconnection)  com¬ 
puter  network  architectures  and  of  open,  distributed 
systems  in  general.  LOTOS  is  based  on  process 
algebras  and  has  nothing  to  do  with  temporal  logic, 
its  name  notwithstanding.  Officially,  LOTOS  is 
based  on  CCS,  but  after  reading  any  description  of 
LOTOS,  it  will  be  clear  that  CSP  has  had  greater 
syntactic  and  semantic  influence. 

Besides  the  basic  process  algebra  to  be  described 
below,  LOTOS  also  has  features  for  describing  data 
structures,  value  expressions,  and  their  types  via  in¬ 
itial  algebraic  specifications  of  abstract  data  types. 

In  LOTOS,  as  in  CCS  and  CSP,  a  distributed  con¬ 
current  system  is  viewed  as  a  process.  A  process 
may  itself  be  composed  of  processes,  called 
sub-processes  to  form  a  hierarchy  of  process  defini¬ 
tions. 

A  process  performs  a  sequence  of  atomic  actions, 
some  of  which  are  internal  and  unobsen'able  and 
others  of  which  interact  with  other  processors  form¬ 
ing  the  external  environment  of  the  process 
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Process  synchronization  is  achieved  by  having  sev¬ 
eral  processes  execute  the  same  event  during  the 
same  state  transition.  A  synchronization  may  in¬ 
volve  exchange  of  data  among  the  processes  partici¬ 
pating  in  the  event.  Notationally  and  semantically, 
these  synchronization  events  are  as  in  CSP.  They 
are  via  like-named  events  in  several  processes  or  via 
a  channel  that  all  processes  have  access  to,  with  one 
process  doing  output  and  the  rest  doing  input  on  that 
channel. 

The  specification  of  a  process  looks  like  that  of  a 
procedure  in  a  programming  language.  A  process 
has  a  name  and  parameters  called  gates.  These  gates 
are  the  ports  by  which  the  communication  channels 
connect  to  the  process.  The  connection  of  at  least 
processes  with  like-named  gates  forms  a  channel 
with  that  same  name.  In  the  body  of  the  process  is 
an  expression  describing  its  composition  in  terms  of 
other  sub-processes  and  events.  As  an  example, 
consider 

process  /Vfax3[(nl,in2,in3,out]  = 
hide  mid  in 
(Max2[in  1  ,in2,mid\ 

\[mid]\ 

Max2[mid,in3,out ]) 
where  ... 
endproc . 

It  is  assumed  that  Maxi  is  a  process  which  outputs 
on  its  third  gate  the  maximum  of  the  values  input  on 
its  first  two  gates.  Max3  is  intended  to  be  a  process 
that  outputs  on  its  fourth  gate  out ,  the  maximum  of 
the  values  input  on  its  first  three  gates  ini,  ini,  m3. 
The  expression 

(Maxl[in\,inl,mid] 

\[mid\\ 

Max2[mid,in3,out)) 

indicates  that  two  instantiations  of  Max 2  are  to  be 
composed  with  the  output  of  the  first,  mid,  being  the 
first  input  of  the  second,  via  a  channel  called  mid. 
The  notation 

\[mid]\ 

is  an  operator  specifying  concurrent,  i.e.,  inter¬ 
leaved,  execution  of  its  two  process  arguments, 
synchronizing  via  the  channel  mid  connection  gates 
named  mid  in  the  two  processes.  Note  that  the  two 
inputs  to  the  first  Maxi  are  the  first  two  inputs  to 
Max3,  the  second  input  to  the  second  Maxi  is  the 
third  input  to  Max 3,  and  the  output  of  the  second 
Maxi  is  the  output  of  Max 3.  The  process  definition 
specifies  that  mid  is  hidden  from  the  external  envi¬ 
ronment  of  Max 3. 

Associated  with  this  process  definition  is  a  diagram 
that  shows  the  physical  composition  of  the  process. 
For  Max 3  the  digram  in  shown  in  Figure  25.  A 
process  is  a  box,  a  channel  is  a  line,  a  gate  is  where  a 
channel  meets  a  process.  A  channel  that  is  entirely 


within  an  enclosing  box  is  hidden  by  the  process  of 
that  box.  A  channel  that  sticks  out  from  a  box  is 
connected  to  an  externally  visible  gate. 

Concurrency  Operators 

In  the  Max3  definition  is  an  example  of  the  most 
general  concurrency  operator  in  LOTOS. 

Given  processes  P  and  Q  and  a  set  of  gates  S,  PISIQ 
is  able  to  perform  any  action  at  a  gate  not  in  S  or  any 
action  that  both  P  and  Q  are  ready  to  perform  at  any 

gate  in  S. 

Note  that  if,  say,  P  is  ready  to  execute  an  action  at 
an  S  gate  and  Q  is  not  ready  to  execute  an  action  at 
the  same  gate,  then  P  must  wait  until  Q  is  ready. 

Another  of  the  concurrency  operators  in  LOTOS  is 
the  “til”  operator,  which  carries  exactly  the  meaning 
of  ISI  with  an  empty  S.  Since  there  is  no  possibility 
of  synchronization,  the  “111"  operator  effectively 
amounts  to  specifying  interleaved  execution,  exactly 
as  in  CSP. 

The  third  concurrency  operator  in  LOTOS  is  the  “|f 
operator  which  is  equivalent  to  ISI  with  S  being  the 
set  of  all  gates  in  the  system.  Thus,  the  two  com¬ 
posed  processes  are  forced  to  proceed  in  complete 
synchrony  except  for  internal  events,  just  as  in  CSP. 

It  is  interesting  that  LOTOS  defines  as  its  basic 
parallelism  operator  something  which  reduces,  as 
special  cases,  to  the  two  main  concurrency  operators 
of  CSP. 

There  are  other  operators  that  are  not  discussed  here 
in  the  interest  of  conserving  space. 

LOTOS  has  been  used  to  specify  a  variety  of  distri¬ 
buted  systems.  Moreover  there  exists  automated 
support  for  the  language,  specifically  tools  to 

•  write  specifications, 

•  validate  and  verify  specifications,  and 

•  compile  specifications  to  C  and  Ada. 

RAISE 

RAISE  (Rigorous  Approach  to  Industrial  Software 
Engineering)  [Nielsen89]  is  an  attempt  to  address  the 
problems  that  prevent  the  Vienna  Development 
Method  (VDM)  from  being  used  in  large-scale  in¬ 
dustrial  software  developments  of  modem  concur¬ 
rent  and  distributed  systems. 

1.  VDM  is  completely  manual. 

2.  The  VDM  specfication  language  lacks  a  satis¬ 
factory  way  to  specify  concurrency.  (This  fact 
kept  it  from  being  considered  in  this  module.) 

3.  The  VDM  specification  language  lacks  a  way 
to  build  abstractions  and  a  way  to  modularize 
specifications  into  managemable,  separable 
pieces. 
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4.  The  VDM  specification  language  lacks  an  ade¬ 
quate  mathematical  semantics. 

The  RAISE  language,  methods,  and  tools  are  aimed 
at  solving  these  problems  by  offering 

1. a  formally  defined,  denotalional  semantics- 
based  specification  language  with  modulariza¬ 
tion  and  abstraction  building  features, 

2.  a  rigorous  method  for  specifying,  validating, 
implmeniing,  and  verifying  the  correctness  of 
systems,  not  unlike  the  methods  assumed  by 
FDM  (See  Section  VI.2)  and  HDM  (See  Sec¬ 
tion  VIA),  and 

3.  a  collection  of  tools  for  editing,  printing, 
checking,  and  verifying  properties  of  specifi¬ 
cations  written  in  the  specifcation  language. 

The  RAISE  specification  language  (RSL)  is  a  wide- 
spectrum  language  in  which  the  main  part  dealing 
with  data  structures  and  the  nonconcurrent  part  of 
algorithms  follows  the  denotationai  frame  and 
strongly  resembles  the  VDM  specification  language. 
The  part  of  the  RSL  that  deals  with  concurrency  is 
based  on  CSP  (hence  the  fact  that  this  discussion  is 
in  this  section). 

10.  ASTRAL 

ASTRAL  [Ghezzi91],  developed  by  Kemmerer  and 
Ghezzi,  is  an  executable  specification  language  for 
describing  real-time  systems.  Its  geneology  is  in¬ 
structive.  Kemmerer  et  al  at  the  University  of  Cali¬ 
fornia  at  Santa  Barbara  developed  ASLAN 
[Auernheimer85]  based  on  Ina  Jo  in  order  to  provide 
an  executable  specification  language  for  roughly  the 
same  class  of  systems  specifiable  in  Ina  Jo. 

Language 

RT-ASLAN  [Auernheimer86]  is  an  extension  of  AS¬ 
LAN  for  specifying  real-time  systems;  it  was  devel¬ 
oped  by  adding  timing  constraints  (in  the  vernacular 
sense  of  the  word)  to  the  transforms  and  constraints 
(in  the  formal  sense  of  the  word)  of  ASLAN.  A 
timing  expression  in  a  transition  specification  speci¬ 
fies  the  time  required  to  execute  the  transition,  i.e., 
the  time  limit  to  which  the  transform  adheres,  while 
that  in  a  constraint  specification  specifies  general 
time  limits  to  which  all  transforms  are  required  to 
adhere.  It  must  be  verified  that  the  time  limits  of  the 
constraint  are  implied  by  those  of  the  transforms. 
One  of  the  strengths  of  ASLAN  and  RT-ASLAN  is 
the  ability  to  structure  specifications  into  smaller 
pieces.  They  allow  layering  and  composition  of 
specifications,  and  the  formalism  allows  reasoning 
about  the  pieces  to  be  composed  into  reasoning 
about  the  whole  specification. 

TRIO  lGhezzi90]  is  a  first-order  logic  language  de¬ 
veloped  at  Politecnico  di  Milano  as  a  formal  nota¬ 
tion  for  specifying  and  verifying  timing  require¬ 


ments.  It  is  formally  defined,  has  the  type  time  con¬ 
sisting  of  numeric  values,  has  the  notions  of  now, 
future,  and  past ,  but  lacks  features  that  would  make 
it  feasible  to  use  for  specifying  real-life  systems.  In 
particular,  it  has  no  modularity  and  no  hierarchical 
structuring,  and  its  realtime  machine-level  formal 
language  makes  reading  specifications  extremely 
difficult  for  any  but  the  writer  of  the  specifications. 
However,  its  formal  definition  makes  it  a  good  basis 
for  a  specification  and  verification  environment. 

Add  to  RT-ASLAN  features  for  modeling  inter¬ 
process  communication  and  specify  the  resulting 
language  by  showing  how  to  translate  any  of  its 
specifications  into  TRIO,  and  you  have  ASTRAL 
From  RT-ASLAN,  ASTRAL  gets  the  modularity 
and  specification  structuring  that  TRIO  lacks,  and 
from  TRIO,  ASTRAL  gets  the  formal  basis  it  needs 
for  a  proof  system  and  specification  execution. 

The  formal  model  for  ASTRAL  is  a  state-machine 
model  like  Ina  Jo's  and  ASLAN’s.  It  assumes  max¬ 
imal  parallelism  with  noninterruptabie  and  nonover¬ 
lapping  transitions  in  a  single  process  instance.  That 
is,  the  model  behaves  as  though  each  process  were 
given  its  own  physical  processor  and  that  physical 
resources,  e.g.,  memory,  available  to  it  are  un¬ 
limited.  A  processor  is  never  idle  when  it  has  a 
transition  available  to  execute,  and  if  no  other  transi¬ 
tion  is  pending,  a  transition  is  executed  as  soon  as  its 
precondition  is  satisfied.  All  variable  updates  of  a 
transition  are  treated  as  taking  place  in  a  single 
atomic  action  occurring  at  the  end  of  the  transition. 

The  reason  for  adopting  this  model  is  that  it  allows 
the  processes  to  be  designed  under  the  assumption  of 
total  independence  except  for  explicitly  specified 
communications.  Such  designs  tend  to  be  cleaner 
than  those  that  deal  also  with  scheduling.  After  the 
design  is  validated,  scheduling  can  be  specified 
separately  to  insist  that  timing  requirements  be  met 
in  the  face  of  the  reality  of  limited  resources. 

Specification  and  Verification 

In  ASTRAL,  a  real-time  system  is  specified  by 
giving  a  collection  of  state-machine  specifications, 
one  for  each  type  of  process,  and  a  single  global 
specification,  for  the  environment  in  which  the  proc¬ 
ess  instances  sit  Each  state  machine  specification 
is,  in  fact,  the  definition  of  a  process  type  in  the  Ada 
sense,  and  there  may  be  multiple  instantiations  of 
this  type  in  the  system  as  a  whole.  The  assumption 
mentioned  above  that  the  transitions  of  the  processes 
are  nonoverlapping  allows  properties  proved  about 
independent  processes  to  be  composed  into 
properties  proved  about  the  whole  system. 

The  state  variables  and  transitions  defined  in  a  proc¬ 
ess  type  specification  may  be  accessed  without  re¬ 
striction  by  any  instance  of  that  type.  Normally 
these  variables  and  transitions  are  not  accessible 
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from  outside  any  containing  process.  However, 
variables  and  transitions  may  be  marked  as  exported, 
in  which  case  they  are  accessible  from  outside,  ft 
appears  from  the  literature  about  ASTRAL  that  from 
outside  the  defining  process,  a  variable  is  read-only. 
Changes  to  such  variables  are  achieved  by  invoking 
exported  transitions  that  do  the  changes  internally. 
All  interprocess  communication  is  via  these  ex¬ 
plicitly  exported  variables  and  transitions.  This 
scheme  is  classic  information  hiding  of  process  type 
definitions. 

Among  the  exported  variables  of  any  process  speci¬ 
fication  are  variables  for  inquiring  the  start  and  en¬ 
ding  time  for  the  fah  last  invocation  of  any  other 
operation  with  or  without  specific  parameter  values 
in  some  or  all  parameter  positions.  These  allow 
writing  of  timing  expressions  that  depend  on  values 
of  variables  and  on  the  history  of  the  computation  so 
far. 

Whereas  RT-ASLAN  used  interface  specifications 
for  interprocess  communication,  ASTRAL  uses  a 
multicast  communication  model,  not  unlike  the 
model  implemented  by  an  Ethernet  or  similar  net¬ 
work  in  which  each  packet  is  made  available  to  all 
nodes  and  a  node  picks  up  only  packets  addressed  to 
it.  In  the  formal  model,  a  message  is  sent  to  all 
processes  and  only  the  target  process  actually  gets  it. 
Formally,  at  the  beginning  of  a  transition,  the  ex¬ 
ecuting  process  broadcasts  the  start  time.  At  the  end 
of  the  transition,  the  executing  process  broadcasts 
both  the  finish  time  and  the  final  values  of  all  ex¬ 
ported  variables  for  receipt  by  all  processes  that 
have  imported  them. 

The  broadcast  itself  is  regarded  as  hiking  place  in¬ 
stantly.  This  way,  the  multicast  can  be  used  to 
model  shared  memory  access  as  well  as  communi¬ 
cation  via  a  point-to-point  channel.  In  the  latter 
case,  the  real  communications  delay  must  be  ex¬ 
plicitly  specified  for  an  appropriate  amount  of  time. 
Moreover,  the  combined  effect  of  universal  broad¬ 
cast  of  the  start  and  finish  times  of  transition  execu¬ 
tions  and  instantaneous  broadcast  is  that  timing 
assertions  in  all  specifications  can  make  use  of  full 
information  about  the  time  of  events  without  there 
being  any  delay  to  obtain  the  timing  information; 
that  is  there  is  no  Heisenberg  effect  built  into  the 
formal  model. 

An  ASTRAL  system  specification  consists  of  a 
global  specification  together  with  a  set  of  individual 
specifications  for  the  process  types  mentioned  as 
use d  in  the  global  specification.  Both  kinds  of  spec¬ 
ifications  have  type,  constant,  and  variable  declara¬ 
tions.  The  variables  of  any  specification  make  up 
the  state  of  whatever  is  described  in  the  specifica¬ 
tion.  As  with  Ina  Jo  and  ASLAN,  a  constant  or 
variable  may  be  a  function  on  values  or  values  and 
variables.  Both  kinds  of  specifications  may  have 


invariant,  constraint,  and  schedule  assertions.  An 
invariant  must  be  true  in  every  state  of  its  containing 
specification,  a  constraint  must  be  true  of  any  transi¬ 
tion  in  its  containing  specification,  and  a  schedule 
assertion  describes  the  timing  of  the  initiation  and 
termination  of  the  transitions  in  its  containing  speci¬ 
fications.  Only  a  nonglobal,  process  specification 
may  have  transition  specifications,  each  describing 
one  state  transition  of  a  process  of  the  type  specified 
by  the  specification  containing  the  transition  specifi¬ 
cation.  Each  transition  specification  has  at  least  one 
pair  of  entry  and  exit  assertions  specifying  the  state 
condition  that  must  be  true  upon  a  normal  invoca¬ 
tion  of  the  transition  and  what  is  true  upon  comple¬ 
tion  of  such  an  invocation.  A  transition  specifica¬ 
tion  may  also  have  any  number  of  exception  and  exit 
assertion  pairs.  Each  specifies  the  state  conditions 
for  a  so-called  exceptional  invocation  of  the  transi¬ 
tion  together  with  the  handling  response  to  that  ex¬ 
ceptional  condition. 

Finally,  only  a  process  specification  may  have  an 
initial  assertion  describing  the  possible  initial  states 
of  any  process  of  the  type  specified  by  the  contain¬ 
ing  specification. 

The  inovation  in  ASTRAL  is  its  ability  to  describe 
time  in  its  assertions.  The  basic  time  primitives  are 
the  notion  of  time  as  a  numeric  value  over  which 
arithmetic  and  ordering  operators  can  be  applied 
plus  some  specific  time  valued  constants  and  func¬ 
tions  such  as  now,  Startit,  and  End(t)  where  t 
denotes  an  invocation  of  a  transition.  Assertions 
about  time  can  appear  in  any  of  the  kinds  of  asser¬ 
tions  described  above.  An  example  of  a  transition 
specification  that  has  timing  assertions  is. 

TRANSITION  Notify_Death 
ENTRY 

Now  -  Start (New_Info)  > 
Timeout 

&  ~Channel_Closed 
EXIT 

Msg [Data_Part ]  =  Closed 

&  Msg[ID_Part]  =  Self 

&  Channel_Closed 

This  specifies  that  the  transition  Notify_Death 
may  be  invoked  only  if  it  has  been  more  than 
Timeout  units  of  time  since  the  start  of  an  invoca¬ 
tion  of  the  New_Info  transition  and  the  channel  is 
not  already  closed. 

A  conjunction  such  as  End  (This) 
start  (This)  <  5  *  n  says  that  the  time  be¬ 
tween  the  start  and  end  of  the  current  invocation  of 
This  transition  no  greater  than  five  times  n  units  of 
time,  where  n  might  be  a  parameter  of  the  current 
transition  or  a  constant,  variable,  or  a  function  built 
from  all  of  them.  If  this  conjunct  appears  in  an  exit 
assertion  of  a  transition  specification,  then  the  cor¬ 
responding  normal  or  exceptional  invocation  is 
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guaranteed  to  finisb  by  the  specified  time.  This  kind 
of  a  conjunct  in  a  schedule  assertion  in  a  process  or 
global  specification  would  be  subject  to  proof  for  the 
process  or  globally  given  what  is  guaranteed  or 
proved  for  the  contained  transitions  or  processes. 

Verification 

Verification  of  an  ASTRAL  specification  follows 
the  same  general  framework  as  in  Ina  Jo.  The  speci¬ 
fication  is  compiled  into  conjectures  written  in  the 
TRIO  language.  These  conjectures  assert  the  fol¬ 
lowing: 

1.  In  each  process  specification, 

•  the  invariant  is  implied  by  the  initial  asser¬ 
tion, 

•  the  invariant  is  preserved  by  each  transi¬ 
tion, 

•  the  constraint  is  implied  by  each  transition; 
and 

2.  in  the  global  specification, 

•  the  invariant  is  implied  by  each  process's 
invariant, 

•  the  constraint  is  implied  by  each  process’s 
constraint, 

•  the  schedule  requirement  is  implied  by 
each  process’s  schedule. 

In  the  above,  when  something  is  implied  by  a  tranL 
tion,  it  is  implied  by  its  entry  and  exit  assertions  pair 
and  by  each  of  its  except  and  exit  assertions  pair. 

Tools 

The  authors  realized  that  a  interpretable  specifica¬ 
tion  language  without  an  interpreter  is  not  very  use¬ 
ful;  therefore  the  design  of  the  language  proceeded 
in  parallel  with  the  design  of  the  environment  for 
compiling  ASTRAL  specifications  into  TRIO  speci¬ 
fications  and  the  TRIO  evaluator.  At  the  present 
time,  a  syntax-directed  ASTRAL  editor  exists  in 
prototype  form.  The  translation  from  ASTRAL  to 
TRIO  is  done  by  hand,  but  a  syntax-directed  trans¬ 
lator  is  under  development.  Finally,  a  TRIO  sym¬ 
bolic  executor,  written  in  PROLOG,  is  available  for 
distribution. 

Actual  Use 

ASTRAL  appears  to  this  author  as  the  first  real-time 
system  specification  language  that  has  a  chance  of 
being  applied  to  the  design  specification  and  verifi¬ 
cation  of  real-time  systems  in  a  way  that  whether  the 
real-time  constraints  are  met  are  subject  to  formal 
mathematical  verification.  ASTRAL  is  too  experi¬ 
mental  to  have  had  any  industrial  strength  applica¬ 
tion. 

VII.  Current  Status 

Of  the  above  described  specification  and  verification 


environments,  at  least  AFFIRM  and  HDM  have  under¬ 
gone  enhancement  to  yield  more  powerful  specification 
languages  and  verification  environments.  AFFIRM  has 
been  upgraded  to  AFF1RM-85  [Musser85a, 
Musser85b).  AFF1RM-85  has  more  facilities  for  struc¬ 
turing  specifications  hierarchically,  and  its  environ¬ 
ment  has  a  library  of  reuseable  proofs. 

The  language  of  Enhanced  HDM  [Rushby9la]  is 
Revised  SPECIAL  [Levitt85J.  It  has  a  number  of  im¬ 
provements  over  SPECIAL,  including  parametcrizable 
modules,  the  use  of  second  order  predicate  calculus, 
and  the  treatment  of  program  operations  as  data  ob¬ 
jects  A  more  powerful  logic  is  needed  in  support  these 
enhancements  [Shostak82].  More  recently,  EHDM  has 
been  used  successfully  to  help  construct  a  verifiably 
correct  distributed  clock  synchronization  algorithm 
[Rushby91b,  Rushby9lc). 

Gypsy  has  been  ported  to  several  other  machines  in¬ 
cluding  Symbolics  machines  [Smith85], 

Another  approach  that  has  been  explored  is  that  of 
symbolic  execution  of  an  operational  model  specifi¬ 
cation,  such  as  AFFIRM,  Ina  Jo,  or  VDL.  UNISEX 
[Kemmerer83,  Kemmerer85]  is  a  successful  implemen¬ 
tation  of  this  idea  for  non-concurrent  programs  written 
in  Pascal.  Inatest  has  been  developed  to  allow  sym¬ 
bolic  execution  of  Ina  Jo  specifications  in  order  to  test 
whether  what  is  desired  equals  what  is  specified 
(Eckmann85).  Others  are  exploring  extending  this  idea 
to  deal  with  Ada  tasking  [Dillon  88a,  Dillon88b, 
Harrison88J. 


Glossary 


asynchronous  execution 

the  appearance  of  parallel  execution  achieved 
through  true  parallel  execution  or  multiplexing, 
in  which  what  happens  next  is  unpredictable, 
and  in  which  the  concept  of  next  may  not  even 
be  meaningful 

bipartite  graph 

an  ordered  graph  with  two  disjoint  sets  of  nodes, 
such  that  for  each  arc,  the  head  and  tail  nodes 
are  in  the  opposite  sets 

concurrent  program 

a  program  whose  execution  consists  of  or  gives 
rise  to  asynchronous  execution 

deadlock 

the  situuation  that  occurs  when  ail  nonter- 
minated  processes  in  a  computation  are  asleep; 
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i.e.,  each  is  waiting  for  a  resource  that  another 
provides;  an  alternative  definition  is  when  at 
least  one  process  is  waiting  for  an  event  that 
cannot  occur 

distributed  computing 

a  collection  of  processors  not  sharing  memory, 
but  sharing  communication  channels  that  allow 
the  processes  on  them  to  communicate  with  each 
other 

fairness 

a  property  of  a  scheduling  algori'hm  that  insures 
that  all  awake  processes  eventually  get  to  run;  if 
a  scheduler  is  fair  then  one  method  of  starvation 
cannot  happen 

interference 

the  act  of  two  or  more  processors  attempting  and 
possibly  succeeding  to  use  the  same  physical  de¬ 
vice  (including  memory  locations)  at  the  same 
time 

multiplexing 

(IEEE;  multitasking)  a  mode  of  operation  in 
which  two  or  more  tasks  are  executed  in  an  in¬ 
terleaved  manner  (by  a  single  processor) 

multiprocessing 

a  mode  of  operation  in  winch  two  or  more  proc¬ 
esses  are  executed  simultaneously  (IEEE  uses 
“concurrently”)  by  separate  processing  units  that 
have  access  to  a  common  main  storage 

nondeterminate 

a  nondeterministic  computation  is  nondeter¬ 
minate  if  the  differing  orders  of  computation 
cause  different  final  results 

nondeterministic 

a  computation  is  nondeterministic  if  at  each 
state,  the  step  to  be  done  next  is  not  defined  by 
the  program  being  computed;  the  choice  of  what 
is  to  be  done  next  is  made  by  an  agent  external 
to  the  program 

parallel  execution 

simultaneous  execution  of  more  than  one  proc¬ 
ess,  which  can  happen  either  in  multiprocessing 
or  distributed  computing 

partial  correctness 

a  form  of  program  correctness  characterized  by 


the  program  meeting  its  requirements  in  all  of  its 
halting  computations;  a  program  is  partially  cor¬ 
rect  if  for  all  input  that  meets  its  input  require¬ 
ments,  the  program  meets  its  output  require¬ 
ments  whenever  it  nalts 

process  item 

a  data  structure  keeping  the  state  of  a  process  in 
the  memory  accessible  to  the  processors  which 
can  execute  on  behalf  of  the  process 

process 

an  execution  of  a  program  or  a  portion  thereof 
process  status 

at  the  level  of  the  program,  a  process  can  be  ei¬ 
ther  awake,  asleep,  or  terminated;  a  process  is 
awake  if  it  is  is  capable  of  running  and  would 
run  if  there  were  sufficient  processors  available 
to  run  it;  a  process  is  asleep  if  it  cannot  run  be¬ 
cause  of  a  condition  defined  in  the  program  it  is 
executing,  i.e.,  it  is  waiting  for  a  resource  from 
another  process  with  which  it  shares  data;  a 
process  is  terminated  if  it  cannot  run  any  more, 
e.g.,  it  has  finished  its  work  or  it  has  committed 
an  unrecoverable  error;  at  the  level  of  the  imple¬ 
mentation,  an  awake  process  is  either  running  or 
ready;  it  is  running  if  a  processor  is  running  it;  it 
is  ready  if  at  the  moment  no  processor  is  avail¬ 
able  to  run  it;  note  the  distinction  between  ready 
and  asleep  processes;  the  latter  could  not  be  run 
even  if  there  were  enough  processors  available 

processor 

an  agent  capable  of  executing  a  program  or  por¬ 
tion  thereof 

program 

(IEEE:computer  program)  a  combination  of 
computer  instructions  and  data  definitions  that 
enable  computer  hardware  to  perform  computa¬ 
tional  or  control  functions 

proper  termination 

if  and  when  a  computation  terminates,  i.e.,  there 
are  no  awake  processes,  then  there  are  no  asleep 
processes  still  waiting  for  a  resource;  proper  ter¬ 
mination  implies  absence  of  deadlock. 

race  condition 

the  situuation  that  occurs  when  the  resolution  of 
interference  for  a  particular  device  can  cause  un¬ 
predictable  results 


SE1-CM-27-1 .0 


47 


Formal  Specification  and  Verification  of  Concurrent  Programs 


real  time 

(IEEE:  real  time)  pertaining  to  a  system  or  mode 
of  operation  in  which  computation  is  performed 
during  the  actual  time  that  an  external  process 
occurs,  in  order  that  the  computation  results  can 
be  used  to  control,  monitor,  or  respond  in  a 
timely  manner  to  the  external  process 

starvation 

the  situuation  that  occurs  when  an  awake  proc¬ 
ess  fails  to  get  any  work  done  because  it  is 
denied  a  resource  it  needs;  either  it  is  busy  wait¬ 
ing  for  a  resource  being  held  on  to  by  another 
process  or  it  is  being  denied  a  processor  by  the 
processor  scheduling  algorithm 

synchronous  execution 

the  absence  of  asynchronous  execution,  in  which 
what  happens  next  is  completely  predictable 

task 

the  same  as  process 
total  correctness 

a  form  of  program  correctness  characterized  by 
the  program  halting  for  all  inputs  and  meeting  its 
requirements  in  all  cases;  a  program  is  totally 
correct  if  for  all  input  that  meets  its  input  re¬ 
quirements,  the  program  halts  and  meets  its  out¬ 
put  requirements 
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Teaching  Considerations 


Suggested  Schedules _ 

There  is  far  more  material  in  this  module  than  can  be 
covered  in  one  semester  or  one  quarter.  Therefore, 
the  instructor  will  have  to  pick  and  choose  from  the 
topics  mentioned  in  the  module. 

Since  the  emphasis  of  the  course  should  be  the  appli¬ 
cation  of  the  formal  methods  of  specification  and 
verification  to  the  development  of  concurrent  soft¬ 
ware,  the  instructor  should  pick  topics  and  methods 
that  he  or  she  is  most  comfortable  working  with  in 
front  of  the  class.  The  instructor  will  have  to  per¬ 
sonally  demonstrate  the  methods  in  front  of  the  stu¬ 
dent  and  will  have  to  be  prepared  to  field  difficult 
questions  from  the  students  and  bug  emergencies  as 
the  students  find  errors  in  what  the  instructor  is 
presenting. 

The  outline  below  represents  how  the  module  author 
would  teach  the  course  based  on  his  own  preferences 
and  familiarities. 

1.  Foundational  Background  (Section  I) 

2.  Ada  Concurrency  Features  (Material 
from  the  module  [Feldman90]) 

3.  Properties  of  Concurrent  Programs 
(Section  II) 

4.  Operational  Models  (Section  III.  1) 

5.  Temporal  Logic  (Section  III.3) 

6.  Specifications  and  Verifications  of 
Protocols  in  Operational  and  Temporal 
Models  (Sections  IV.3  and  V) 

7.  Use  of  FDM  and  SARA  to  do  these  spec¬ 
ifications  and  verifications  (Sections 
VI.3  and  VI.7) 

Of  course,  the  instructor  who  wishes  to  follow  a 
similar  outline  but  is  not  comfortable  with  the  spe¬ 
cific  languages,  methods,  and  tools,  could  use 
others,  e.g.,  Concurrent  Pascal,  Axiomatic  Seman¬ 
tics,  Operating  System  Security,  and  AFFIRM. 

The  module  author  considers  it  critical  to  cover 
Topics  1,  foundational  background,  and  2,  some 
language’s  concurrency  features.  The  students  need 
this  material  to  make  what  follows  an  abstraction  of 
concepts  they  already  know  rather  than  totally  new 
material  from  which  they  may  derive  an  understano- 
ing. 


Worked  Examples _ 

The  worked  examples  should  be  sufficiently  com¬ 
plex  that  the  act  of  specifying  them  actually  teaches 
the  students  about  the  function  of  the  software. 
Protocols  are  ideal  for  this  because  they  are  gener¬ 
ally  difficult  to  understand  without  some  model.  For 
example,  the  students  might  be  shown  in  lectures 
formal  definitions  of  the  Alternating  Bit  protocol  in 
each  of  the  languages  and  notations  covered. 


Exercises _ 

If  the  class  goals  include  the  ability  to  write  specifi¬ 
cations  of  concurrent  systems,  then  in  all  probability, 
the  instructor  will  be  writing  some  specifications  in 
front  of  the  students  in  class.  Then,  as  homework, 
the  students  should  be  asked  to  define  another  more 
complex  protocol,  say,  Stenn ing’s  Data  Transfer 
Protocol  [Sunshine82],  in  each  of  the  same  lan¬ 
guages  and  notations  and  to  prove  implementation  of 
the  basic  service  protocol,  safety,  and  liveness 
properties. 

It  would  be  useful  to  get  a  copy  of  or  get  access  to 
one  of  the  formal  specification  and  verification  envi¬ 
ronments  so  that  students  can  attempt  to  use  these  in 
which  to  carry  out  their  assigned  specifications  and 
verifications. 

From  where  can  these  environments  be  obtained? 
Below  is  information  on  how  to  obtain  environments 
for  most  of  the  languages  covered  in  detail  in  Sec¬ 
tion  VI.  Note  that  although  the  module  author  has 
seen  some  of  these  environments  in  operation,  he 
has  never  tried  porting  any  of  them  from  its  original 
site. 

PAISLey 

As  mentioned  earlier,  the  PAISLey  environment,  in¬ 
cluding  the  processor  and  other  tools,  is  sold  through 
AT&T’s  UNIX  toolchest.  Use  the  UNIX  toolchest, 
dial  the  computer  at  201-522-6900  and  log  in  as 
guest.  The  system  will  prompt  you.  The  environ¬ 
ment  is  also  available  free  to  any  academic  institu¬ 
tion.  Faculty  members  interested  in  ordering  it 
should  send  to  Pamela  Zave  a  request  for  the  envi¬ 
ronment  on  institutional  letterhead.  Her  address  is 
Dr.  Pamela  Zave,  Software  and  Systems  Research 
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Center,  AT&T  Bell  Laboratories,  Room  3D-426, 
Murray  Hill,  NH  07974,  U.S.A.,  e-mail: 

pamela@allegra.att.com. 

AFFIRM 

Work  has  ceased  on  AFFIRM  entirely.  The  original 
AFFIRM,  developed  at  ISI,  runs  on  only  the  PDP  10 
class  machines,  and  there  appear  to  be  none  around 
except  in  museums. 

According  to  David  Musser,  the  leader  of  the  project 
to  develop  AFFIRM-85,  Affirm-85,  a  version  of  Af¬ 
firm  available  from  Rensselaer  Polytechnic  Institute, 
runs  on  VAX/VMS  machines.  No  license  for 
Affirm-85  is  required,  and  no  support  is  provided , 
but  licenses  are  required  for  Interlisp-VAX  from 
DEC  (at  least  a  run-time  license)  and  for  Unipress 
Emacs  (which  is  used  as  part  of  the  user  interface) 
from  Unipress,  Inc.  Affirm-85  was  developed  at 
General  Electric  Corporate  Research  and  Develop¬ 
ment  Center  (as  a  porting  and  extension  of  the  orig¬ 
inal  Affirm  system  developed  at  USC/Information 
Sciences  Institute)  but  is  in  the  public  domain,  as  it 
was  sponsored  by  the  U.S.  Air  Force.  It  may  also  be 
possible  to  get  Affirm-85  from  Rome  Air  Develop¬ 
ment  Center,  Griffiths  Air  Force  Base,  Rome,  NY 
(John  Faust).  The  distribution  tape  from  Rensselaer 
includes  the  source  files  and  a  binary  executable  file. 
Documentation  describing  installation  procedures 
and  differences  from  the  original  ISI  Affirm  system 
is  included  (copies  of  the  original  Affirm  documen¬ 
tation  may  also  be  obtained  from  Rensselaer,  or 
from  ISI).  A  nominal  charge  will  be  made  for  tape 
copying  and  document  reproduction.  Send  inquiries 
to  Professor  David  Musser,  Rensselaer  Polytechnic 
Institute,  Computer  Science  Department,  Amos 
Eaton  Hall,  Troy,  NY  12180,  U.S, A.,  e-mail: 
musser@turing.cs.rpi.edu. 

GYPSY  VERIFICATION  ENVIRONMENT  (GVE) 

The  GVE  is  available  for  distribution  subject  to  cer¬ 
tain  export  restrictions  imposed  by  the  U.S.  govern¬ 
ment.  The  GVE  is  a  free  product  though  there  are 
some  conditions  for  release.  Requests  can  be  sent  to 
Ron  Olphie,  Computational  Logic,  Inc.,  1717  W.  6th 
Street,  Suite  290,  Austin,  TX  78703,  U.S. A.,  email: 
olphie@cli.com  512-322-9941. 

Various  system  documentation,  including  a  user’s 
manual,  is  available.  These  consist  mainly  of  Com¬ 
putational  Logic,  Inc.  technical  reports.  Contact  Ron 
Olphie  at  the  address  above  to  obtain  this  documen¬ 
tation. 

FDM 

The  FDM  environment  for  Sun  3’s  is  available  at  no 


cost  for  as  long  as  the  cost  continues  to  be  covered 
by  National  Computer  Security  Center.  Please  con¬ 
tact  Deborah  Cooper,  Unisys  Corp.,  Formal  Methods 
5731  Slauson  Ave.,  Culver  City,  CA  90230, 
213-338-3727,  e-mailxooper@culv.unisys.com  for 
details.  Available  with  the  distribution  is  a  full  set 
of  user  documentation,  including  the  FDM  User 
Guide  with  a  complete  tutorial  example.  Unisys  also 
offers  a  two-week  Advanced  FDM  Course  empha¬ 
sizing  hands-on  experience.  This  course  includes  re¬ 
views  of  first  order  logic  and  state  machines.  There 
is  a  plan  to  develop  a  Basic  Course,  as  a  prerequisite 
to  the  Advanced  course,  for  brand  new  users. 

Unisys  has  recently  developed  the  Model  Executor 
as  a  simulator  of  Ina  Jo  specifications.  It  has  proved 
to  be  a  good  pedagogical  tool  for  understanding  the 
semantics  of  Ina  Jo  and  Ina  Jo  specifications.  It  is 
written  in  Quintus  Prolog.  Therefore,  a  site  not  al¬ 
ready  licensed  for  Quintus  Prolog  must  pay  a 
$400.00  licensing  fee  to  run  the  Model  Executor. 
The  Model  Executor  is  accompanied  by  documen¬ 
tation,  Model  Executor  User  Guide. 

HDM 

The  original  HDM  no  longer  exists.  There  is  an 
newer  version  of  the  method,  called  EHDM.  EHDM 
has  been  developed  by  the  Computer  Science  Labo¬ 
ratory  (CSL)  of  SRI  International  for  the  U.S.  Gov¬ 
ernment  and  is  therefore  in  the  Public  Domain.  SRI 
International  has  no  wish  to  restrict  the  availability 
of  EHDM,  but  distribution  of  the  EHDM  system  and 
its  documentation  is  subject  to  controls  imposed  by 
the  U.S.  Government.  Permission  to  obtain  copies 
of  the  EHDM  system  is  generally  routine  for  Agen¬ 
cies  of  the  U.S.  Government,  and  for  U.S.  Corpora¬ 
tions  working  on  U.S.  Government  contracts. 
Policies  on  wider  distribution  are  unclear  a  present. 

Those  interested  in  using  EHDM  L  xs  d  contact 
John  Rushby  at  the  Computer  Scieve  laboratory, 
SRI  International,  333  Ravenswood  Avenue,  Menlo 
Park,  CA  94025  USA,  415-859-5456,  FAX. 
415-859-2844,  e-mail:  rushby@csl.sri.com. 

EHDM  Version  5.1.4  is  currently  available  for 
Sun-3  and  Sun-4  workstations  (Symbolics  machines 
are  no  longer  supported).  At  least  8  MB  of  real 
memory  (16  MB  recommended),  35  MB  of  swap 
space  (50  MB  recommended),  and  about  32  MBytes 
of  file  space  are  required.  EHDM  is  implemented  in 
Sun  Common  Lisp  and  you  will  need  the  appropriate 
RTU  license  from  Sun.  A  full  GNU  Emacs  is 
needed  since  EHDM  uses  this  as  its  interface. 

The  documentation  available  includes  a  Language 
manual,  a  System  manual,  a  Formal  Semantics,  and 
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a  rather  good  Tutorial.  These  are  all  available  the 
same  restrictions  mentioned  above. 


SARA 


The  old  SARA  system  is  not  available  and  the  latest 
CoSARA  (Cooperative  SARA)  is  not  ready  for  dis¬ 
tribution.  CoSARA  will  allow  several  designers  to 
be  working  on  the  same  design  at  the  same  time 
from  different  workstations. 

P-NUT 


P-NUT  is  distributed  as  part  of  the  standard  Arcadia 
distribution  tape.  There  is  a  licensing  agreement  that 
must  be  signed,  and  there  is  a  nominal  distribution 
fee.  For  further  information  about  the  Arcadia  dis¬ 
tribution,  please  contact  Professor  Richard  Taylor, 
Information  &  Computer  Science  Department,  Uni¬ 
versity  of  California,  Irvine,  CA  92717,  U.S.A.  e- 
mail:  taylor@ics.uci.edu. 

STATEMATE 


STATEMATE  may  be  licensed  on  a  commercial 
basis  from  i-Logix,  Inc.,  22  Third  Avenue,  Bur¬ 
lington,  MA  01803,  U.S.A.,  617-272-8090,  FAX: 
617-272-8035.  It  is  available  on  a  number  of 
hardware  platforms  including  VAX/VMS.  It  comes 
with  a  graphic  user  interface  for  constructing  the 
models  and  an  analyzer  for  analyzing  and  simulating 
models. 


Caveats 


Beware  of  typographical  errors  in  textbooks  adopted 
for  any  course.  While  you,  the  instructor,  can  wea¬ 
ther  these  errors,  the  students  may  not  be  able  to  dis¬ 
tinguish  between  their  own  misunderstanding  and 
genuine  errors  in  the  text. 
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language  to  specify  the  run-time  semantics  of  the 
programming  language  PL/l. 

Bel  173 

Bell,  D.E.  and  L.J.  LaPadula.  Secure  Computer  Sys¬ 
tems:  Mathematical  Foundations  and  Model.  ESD- 
TR-73-278,  Volumes  1  and  2,  The  MITRE  Corpo¬ 
ration,  Bedford,  MA,  1973. 

This  paper  defines  the  basic  model  of  data  security 
that  almost  everyone  uses  to  specify  system 
security.  It  has  the  concept  of  subjects  (processes) 
of  different  levels  of  clearance  having  access  to  ob¬ 
jects  (files)  of  different  levels  of  sensitivity. 

Ben-Ari81 

Ben-Ari,  M.,  Z.  Manna,  and  A.  Pnueli.  “The  Tem¬ 
poral  Logic  of  Branching  Time.”  Conference  Record 
of  Eighth  Annual  ACM  Symposium  on  Principles  of 
Programming  Languages.  New  York:  ACM,  Jan. 
1981,  164-176. 

Abstract:  A  temporal  language  and  system  are 
presented  which  are  based  on  branching  lime  struc¬ 
ture.  By  the  introduction  of  symmetrically  dual  sets 
of  temporal  operators,  it  is  possible  to  discuss 
properties  which  hold  either  along  one  path  or 
along  all  paths.  Consequently  it  is  possible  to  ex¬ 
press  in  this  system  all  the  properties  that  were 
previously  expressible  in  linear  time  or  branching 
time  systems.  We  present  an  exponential  decision 
procedure  for  satisfiability  in  the  language  based 
on  tableaux  methods,  and  a  complete  deduction  sys¬ 
tem.  An  associated  temporal  semantics  is  il¬ 
lustrated  for  both  structured  and  graph  represen¬ 
tations  of  programs. 
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Benzel84 

Benzel,  T.  “Further  Analysis  of  the  SCOMP  System 
Verification.”  Seventh  Dod/NBS  Security 
Conference.  Arlington.  Virginia:  DoD  Computer 
Security  Evaluation  Center,  Sept.  1984. 

This  paper  is  one  in  a  series  that  examines  the  for¬ 
mal  verification  process  used  to  certify  the  SCOMP 
operating  system  This  is  a  long  and  stringent  math¬ 
ematical  process  that  is  required  to  prove  formally 
the  protection  properties  of  a  system.  It  is  notewor¬ 
thy  that  SCOMP  is  certified  A1  under  the  Orange 
Book  criterion  by  the  US  DoD. 

Berg82 

Berg,  H.K.,  W.E.  Boebert,  W.R.  Franta,  and  T.G. 
Moher.  Formal  Methods  of  Program  Verification 
and  Specification.  Englewood  Cliffs,  NJ:  Prentice- 
Hall,  1982. 

The  book  has  a  wide-ranging  survey  of  verification. 
Chapter  6  deals  with  correctness  of  parallel  pro¬ 
grams  and  surveys  several  methods  of  dealing  with 
shared-memory  parallelism  and  interference.  The 
bibliography  is  extensive  with  166  ■'ntries. 

Bernstein87 

Bernstein,  P.A.,  V.  Hadzilacos,  and  N.  Goodman. 
Concurrency  Control  and  Recovery  in  Database 
Systems.  Reading,  MA:  Addison-Wesley,  1987. 

This  book  has  a  tutorial  explanation  of  two-phase 
commit. 

Berry72 

Berry,  D.M.  “The  Equivalence  of  Models  of 
Tasking."  ACM  SIGPLAN  Notices  7,  1  (Jan.  1972), 
170-190. 

Abstract:  A  technique  for  proving  the  equivalence 
of  implementations  of  multi-tasking  programming 
languages  is  developed  and  applied  to  proving  the 
equivalence  of  the  contour  model  and  a  multi¬ 
tasking  version  of  the  copy  rule. 

Berry85 

Berry,  D.M.  “A  Denotationa!  Semantics  for  Shared- 
Memory  Parallelism  and  Nondeterminism.”  Acta  In- 
formatica  21  (1985),  599-627. 

Abstract:  It  is  first  shown  how  to  construct  a  con¬ 
tinuation  from  a  deterministic  Vienna  Definition 
Language  control  tree.  This  construction  is  then 
applied  to  nondeterministic  control  trees.  The 
result  is  a  denotational  but  not  quite  continuation 
semantics  for  arbitrary  shared-memory  nondeter¬ 
minism  and  parallelism.  The  implications  of  this 
result  are  discussed. 


Berztiss87 

Berztiss,  A.  Formal  Specification  of  Software.  Cur¬ 
riculum  Module  SEI-CM-8,  DT1C:  ADA  236262, 
Software  Engineering  Institute,  Carnegie  Mellon 
University,  Pittsburgh,  Pa.,  Oct.  1987. 

(From  Capsule  Description)  This  module  intro- 
uduces  methods  for  the  formal  specification  of  pro¬ 
grams  and  large  software  systems,  and  reviews  the 
domains  of  application  of  these  methods.  Its  em¬ 
phasis  is  on  the  functional  properties  of  software.  It 
does  not  deal  with  the  specification  of  programming 
languages,  the  specification  of  user-computer  inter¬ 
faces,  or  the  verification  of  programs.  Neither  does 
it  attempt  to  cover  the  specification  of  distributed 
systems. 

Berztiss88 

Berztiss,  A.  and  M.A.  Ardis.  Formal  Verification  of 
Programs.  Curriculum  Module  SEI-CM-20,  DTIC. 
ADA  235775,  Software  Engineering  Institute,  Car¬ 
negie  Mellon  University,  Pittsburgh,  Pa.,  Dec.  1988. 

(From  Capsule  Description)  This  module  introduces 
formal  verification  of  programs.  It  deals  primarily 
with  proofs  of  sequential  programs,  but  also  with 
consistency  proofs  for  data  types  and  deduction  of 
particular  behaviors  of  programs  from  their  specifi¬ 
cations.  Two  approaches  are  considered:  verifica¬ 
tion  after  implementation  that  a  program  is  consis¬ 
tent  with  its  specification,  and  parallel  development 
of  a  program  and  its  specification.  An  assessment 
of  formal  verification  is  provided. 

Bevier87 

Bevier,  W.R.  A  Verified  Operating  System  Kernel. 
Technical  Report  11,  Computational  Logic,  Inc., 
Austin,  TX,  1987. 

Abstract:  We  present  a  multitasking  operating  sys¬ 
tem  kernel,  called  KIT,  written  in  the  machine  lan¬ 
guage  of  a  uni-processor  von  Neumann  computer 
The  kernel  is  proved  to  implement,  on  this  shared 
computer,  a  fixed  number  of  conceptually  distribu¬ 
ted  communicating  processes.  In  addition  to  im¬ 
plementing  processes,  the  kernel  provides  the  fol¬ 
lowing  verified  services:  process  scheduling,  error 
handling,  message  passing,  and  an  interface  to 
asychchronous  devices.  The  problem  is  stated  in 
the  Boyer-Moore  logic  and  the  proof  is  mechani¬ 
cally  checked  with  the  Boyer-Moore  theorem 
prover. 

Bolognesi87 

Bolognesi,  T.  and  E.  Brinksma.  “Introduction  to  the 
ISO  Specification  Language  LOTOS.”  Computer 
Networks  and  ISDN  Systems  14  (1987),  25-59. 

Abstract:  LOTOS  is  a  specification  language  that 
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has  been  specifically  developed  for  the  formal  de¬ 
scription  of  the  OSI  (Open  Systems  Interconnection) 
architecture ,  although  it  is  applicable  to  distribu¬ 
ted,  concurrent  systems  in  general.  In  LOTOS,  a 
system  is  seen  as  a  set  of  processes  which  interact 
and  exchange  data  with  each  other  and  their  envi¬ 
ronment.  LOTOS  is  expected  to  become  an  ISO 
standard  by  1988. 

Britton84 

Britton,  D.E.  "Formal  Verification  of  a  Secure  Net¬ 
work  with  End-to-End  Encryption.”  Proceedings  of 
the  1984  Symposium  on  Security  and  Privacy. 
Washington,  DC:  IEEE  Computer  Society,  April 
1984. 

Abstract:  4  formal  specification  and  verification  of 
a  simple  secure  communications  network  using  end- 
to-end  encryption  is  presented.  It  is  shown  that  all 
data  sent  over  the  network  is  encrypted  and  all 
hosts  on  the  network  exchange  messages  only  if  they 
are  authorized  to  do  so.  The  network  and  its  hosts 
are  modelled  by  a  set  of  concurrent  processes  that 
communicate  via  unidirectional  buffers.  Each  proc¬ 
ess  is  viewed  as  a  state  machine.  The  specification 
has  been  formally  verified  using  the  comtnercially 
available  VERUS  verification  system. 

Bustard90 

Bustard,  D.W.  Concepts  of  Concurrent 
Programming.  Curriculum  Module  SEI-CM-24, 
DTIC:  ADA  223897,  Software  Engineering  Insti¬ 
tute,  Carnegie  Mellon  University,  Pittsburgh,  Pa., 
April  1990. 

(From  Capsule  Description)  A  concurrent  program 
is  one  defining  actions  that  may  be  performed 
simultaneously.  This  module  discusses  the  nature 
of  such  programs  and  provides  an  overview  of  the 
means  by  which  they  may  be  constructed  and  ex¬ 
ecuted.  Emphasis  is  given  to  the  terminology  used 
in  this  field  and  the  underlying  concepts  involved. 

Camilleri90 

Camilleri,  A.J.  “Mechanizing  CSP  Trace  Theory  in 
Higher  Order  Logic.”  IEEE  Trans,  Software  Eng. 
16,  3  (Sept.  1990),  993-1004. 

Abstract:  The  process  algebra  CSP  is  widely  used 
for  formal  reasoning  in  the  areas  of  concurrency, 
communication,  and  distributed  systems.  Math¬ 
ematical  proof  plays  a  key  role  in  CSP  reasoning, 
but  despite  this,  little  mechanical  proof  support  has 
been  developed  for  CSP  to  facilitate  the  exercise 
and  eliminate  the  risk  of  human  error.  In  this  paper 
we  described  how  a  mechanized  toot  for  reasoning 
about  CSP  can  be  developed  by  customizing  an  ex¬ 
isting  general-purpose  theorem  prover  based  on 
higher  order  logic.  We  investigate  how  the  trace 


semantics  of  CSP  operators  can  be  mechanized  m 
higher  order  logic,  and  show  how  the  laws  associ¬ 
ated  with  these  operators  can  be  proved  from  their 
semantic  definitions.  The  resulting  system  is  one  in 
which  natural-deduction  style  proofs  can  be  con¬ 
ducted  using  the  standard  CSP  laws 

C handy 88 

Chandy,  K.M.  and  J.  Misra.  Parallel  Program 

Design.  Reading,  MA:  Addison-Wesley,  1988. 

This  book  defines  the  UNITY  parallel  program  de¬ 
sign  language  and  and  develops  a  complete  theory 
of  programming  with  UNITY  and  of  the  meaning  of 
UNITY  programs. 

Cheheyl81 

Cheheyl,  M.H.,  M.  Gasser,  G.A.  Huff,  and  J.K.  Mil- 

len.  “Verifying  Security.”  ACM  Computing  Survexs 

13,  3  (Sept.  1981),  279-340. 

Abstract:  Four  automated  specification  and  verifi¬ 
cation  environments  are  surveyed  and  compared: 
HDM,  FDM,  Gypsy,  and  AFFIRM.  The  emphasis 
of  the  comparison  is  on  the  way  these  systems  could 
be  used  to  prove  security  properties  of  an  operating 
system  design. 

The  acronyms  HDM  and  FDM  stand  for  Hierar¬ 
chical  Development  Methodology  and  Formal  De¬ 
velopment  Methodology,  respectively.  HDM  is 
based  on  the  specification  language  SPECIAL,  and 
the  (non-interactive)  Boyer-Moore  theorem  prover. 
FDM  makes  use  of  the  Ina  Jo  specification  language 
and  an  interactive  theorem  prover.  Gypsy  is  a 
highly  integrated  euviroiunciU  intended  for  Die  in¬ 
cremental  verification  of  software.  In  AFFIRM, 
software  development  is  regarded  as  the  specifica¬ 
tion  and  implementation  of  abstract  data  types,  and 
specifications  are  written  as  algebraic  axioms.  Al¬ 
though  this  survey  deals  specifically  with  the  verifi¬ 
cation  of  security,  it  provides  clear  descriptions  of 
the  four  verification  methodologies  listed  above  and 
is  an  invaluable  guide  to  further  reading.  The 
largest  application  example  known  at  the  time  is 
indicated  for  each  environment. 

Chen83 

Chen,  B.S.  and  R.T.  Yeh.  "Formal  Specification  and 

Verification  of  Distributed  Systems.”  IEEE  Trans. 

Software  Eng.  SE-9, 6  (Nov.  1983),  710-722. 

Abstract :  Computations  of  distributed  systems  are 
extremely  difficult  to  specify  and  verify  using  tradi¬ 
tional  techniques  because  the  systems  are  inherently 
concurrent,  asynchronous,  and  nondeterministic. 
Furthermore,  computing  nodes  in  a  distributed  sys¬ 
tem  may  be  highly  independent  of  each  other,  and 
the  entire  system  may  lack  an  accurate  global  clock. 
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In  this  paper,  we  develop  an  event-based  model  to 
specify  formally  the  behavior  (the  external  view) 
and  the  structure  (the  internal  view)  of  distributed 
systems.  Both  control-related  and  data-related 
properties  of  distributed  systems  are  specified  using 
two  fundamental  relationships  among  events:  the 
"precedes"  relation,  representing  time  order;  and 
the  “ enables "  relations,  representing  causality.  No 
assumption  about  the  existence  of  a  global  dock  is 
made  in  the  specifications. 

The  specification  technique  has  a  rather  wide  range 
of  applications.  Examples  from  different  classes  of 
distributed  systems,  include  communication  sys¬ 
tems,  process  control  systems,  and  a  distributed 
prime  number  generator,  are  used  to  demonstrated 
the  power  of  the  technique. 

The  correctness  of  a  design  can  be  proved  before 
implementation  by  checking  the  consistency  be¬ 
tween  the  behavior  specification  and  the  structure 
specification  of  a  system.  Both  safety  and  liveness 
properties  can  be  specified  and  verified.  Further¬ 
more,  since  the  specification  technique  defines  the 
orthogonal  properties  of  a  system  separately,  each 
of  them  can  be  verified  independently.  Thus,  the 
proof  technique  avoids  the  exponential  state- 
explosion  problem  found  in  state-machine  specifi¬ 
cation  techniques. 

Cleaveland89 

Cleaveland,  R.,  J.  Parrow,  and  B.  Steffen.  The  Con¬ 
currency  Workbench:  a  Semantics  Based  Tool  for 
the  Verification  of  Concurrent  Systems.  LFCS  re¬ 
port  series,  ECS-LFCS-89-83,  Dept,  of  Computer 
Science,  University  of  Edinburgh,  Edinburgh,  UK. 
1989. 

Abstract:  The  Concurrency  Workbench  is  an  auto¬ 
mated  tool  that  caters  for  the  analysis  of  networks 
of  finite-state  processes  expressed  in  Milner's  Cal¬ 
culus  of  Communicating  Systems.  Its  key  feature  is 
its  scope:  a  variety  of  different  verification  methods, 
including  equivalence  checking,  preorder  checking, 
and  model  checking,  are  supported  for  several  dif¬ 
ferent  process  semantics.  One  experience  from  our 
work  is  that  a  large  number  of  interesting  verifi¬ 
cation  methods  can  be  formulated  as  combinations 
of  a  smaller  number  of  primitive  algorithms.  The 
Workbench  has  been  applied  to  examples  involving 
the  verification  of  communications  protocols  and 
mutual  exclusion  algorithms  and  has  proven  a  valu¬ 
able  aid  in  teaching  and  research. 

Cohen86 

Cohen,  B.,  W.T.  Harwood,  and  M.I.  Jackson.  The 
Specification  of  Complex  Systems.  Wokingham, 
England:  Addison-Wesley,  1986. 

This  brief,  143  page  book  explores  some  aspects  of 
the  electronic  office  by  means  of  equational  al¬ 


gebraic  specification  and  the  Vienna  Development 
Method  (VDM).  Chapter  6  covers  specification  of 
concurrent  systems.  Chapter  7  describes  formal 
methods  in  the  development  environment.  This 
chapter  includes  a  listing  of  centers  of  current  re¬ 
search  activity  in  the  more  theoretical  approaches  to 
specification,  and  of  experimental  specification  lan¬ 
guages. 

Comer84 

Comer,  D.  Operating  System  Design:  the  Xinu 
Approach.  Englewood  Cliffs,  NJ:  Prentice-Hall, 
1984. 

This  book  describes  the  Xinu  system,  similar  to  the 
UNIX  kernel,  that  runs  on  the  LSI-1 1  minicomput¬ 
er.  The  book  describes  and  gives  the  complete  C 
code  for  the  system. 

Cousot82 

Cousot,  P.  and  R.  Cousot.  “Induction  Principles  for 
Proving  Invariance  Properties  of  Programs.”  In 
Tools  and  Notions  for  Program  Construction, 
D.  Neel,  ed.  Cambridge,  England:  Cambridge  Uni¬ 
versity  Press,  1982, 75-1 19. 

Abstract:  We  propose  sixteen  sour,  1  and  complete 
induction  principles  for  proving  program  in¬ 
variance  properties.  We  study  their  relationships 
and  show  that  they  can  be  derived  from  each  other 
by  commuting  mathematical  transformations.  Only 
five  of  these  induction  principles  correspond  to  al¬ 
ready  known  invariance  proof  methods.  We  choose 
a  non-conventional  induction  principle  and  con¬ 
struct  corresponding  partial  correctness,  non- 
termination  and  clean  behavior  proof  methods 
When  constructing  these  new  proof  methods,  we  in- 
fonnally  apply  our  mathematical  approach 
published  earlier.  This  essentially  consists  in 
decomposing  the  global  inductive  invariant  in¬ 
volved  in  the  induction  principle  into  an  equivalent 
set  of  local  invariants  and  in  deriving  the  cor¬ 
responding  verification  condition. 

Dennis68 

Dennis,  J.B.  “Programming  Generality,  Parallelism, 
and  Computer  Architecture.”  In  Information  Proc¬ 
essing  68.  Amsterdam:  North-Holland,  1968, 
484-492. 

Abstract:  Parallelism  and  programming  generality 
are  increasingly  important  attributes  of  computer 
systems.  Yet  their  joint  influence  on  computer  ar¬ 
chitecture  has  not  been  felt.  In  this  paper,  a  pro¬ 
gram  graph  description  of  algorithms  is  developed 
that  meets  the  requirements  of  programming  gener¬ 
ality  and  allows  asynchronous  parallel  execution 
without  loss  of  determinism.  A  machine  organi¬ 
zation  inspired  by  the  prog) am  graph  models  is 
sketched. 


SEI-CM-27-1 .0 


57 


Formal  Specification  and  Verification  of  Concurrent  Programs 


Dijkstra68 

Dijkstra,  E.W.  “The  Structure  of  ‘THE’  Mul¬ 
tiprogramming  System.”  Comm.  ACM  II,  5  (May 
1968),  341-346. 

Abstract:  A  multiprogramming  system  is  described 
in  which  all  activities  are  divided  over  a  number  of 
sequential  processes.  These  sequential  processes 
are  placed  at  various  hierarchical  levels,  in  each  of 
which  one  or  more  independent  abstractions  have 
been  implemented.  The  hierarchical  structure 
proved  to  be  vital  for  the  verification  of  the  logical 
soundness  of  the  design  and  the  correctness  of  its 
implementation. 

Dijkstra76 

Dijkstra,  E.W.  A  Discipline  of  Programming. 
Englewood  Cliffs,  NJ:  Prentice-Hall,  1976. 

The  topic  of  weakest  preconditions  is  developed  by 
the  master  himself.  The  book  has  no  index  and  no 
bibliography. 

Dillon88a 

L.K.  Dillon,  R.A.  Kemmerer,  and  L.J.  Harrison.  An 
Experience  with  Two  Symbolic  Execution- Based  Ap¬ 
proaches  to  Formal  Formal  Verification  of  Ada 
Tasking  Programs.  TRCS88-6,  Department  of 
Computer  Science,  University  of  California,  Santa 
Barbara,  CA,  1988. 

Abstract :  There  have  been  several  efforts  to  use 
symbolic  execution  to  test  and  analyze  concurrent 
programs.  Recently  proof  systems  have  also 
emerged  for  concurrent  programs  and  for  the  Ada 
language  in  particular.  This  paper  reports  on  an 
experience  with  developing  two  different  ap¬ 
proaches,  which  use  symbolic  execution,  to  prove 
partial  correctness  and  general  safety  properties  of 
Ada  programs.  One  approach  is  based  upon  inter¬ 
leaving  the  task  components  while  the  other  is 
based  upon  verifying  the  tasks  in  isolation  and  then 
performing  cooperation  proofs.  Both  approaches 
extend  past  efforts  fry  incorporating  tasking  proof 
rules  into  the  symbolic  executor  allowing  Ada  pro¬ 
grams  with  tasking  to  be  formally  verified. 

The  limitations  of  each  approach  are  presented, 
along  with  each  approach's  advantages  and  dis¬ 
advantages.  In  particular,  the  difficulty  of  dealing 
with  communication  statements  in  a  loop  structure 
are  addressed  in  detail. 

Dillon88b 

Dillon,  L.K.  “Symbolic  Execution- Based  Verifica¬ 
tion  of  Ada  Tasking  Programs.”  Proceedings  of 
Third  International  IEEE  Conference  on  Ada  Ap¬ 
plications  and  Environments.  Washington,  DC: 
IEEE  Computer  Society,  May  1988,  3-13. 


Abstract:  Symbolic  execution  has  been  used  suc¬ 
cessfully  with  sequential  programs  for  generating 
the  verification  conditions  required  for  correctness 
proofs.  This  paper  shows  how  the  sy  mbolic  execu¬ 
tion  model  for  sequential  programs  can  be  extended 
to  a  tasking  subset  of  Ada.  The  criteria  for  correct 
operation  of  a  concurrent  program  include  safety 
properties,  such  as  mutual  exclusion  and  freedom 
from  deadlock.  The  extended  model,  therefore  pro¬ 
vides  a  basis  for  the  automatic  generation  of  verifi¬ 
cation  conditions  for  proving  general  safetv 
properties  of  Ada  tasking  programs. 

Dillon92 

Dillon,  L.K.  A  Visual  Execution  Model  for  Ada 
Tasking.  Technical  Report,  Department  of  Comput¬ 
er  Science,  University  of  California,  Santa  Barbara, 
CA.  1992. 

Abstract:  A  visual  execution  model  for  Ada  tasking 
can  help  programmers  attain  a  deeper  understand¬ 
ing  of  the  tasking  semantics.  It  can  illustrate  sub- 
telties  in  semantic  definitions  that  are  not  apparent 
in  natural  language  descriptions  of  Ada  tasking,  as 
well  as  the  consequences  of  choices  made  in  the 
language  design. 

We  describe  a  contour  model  of  Ada  tasking  that 
pictorially  depicts  asynchronous  tasks  (threads  of 
execution),  relationships  between  the  environments 
in  which  tasks  execute  and  the  manner  in  which 
tasks  interact.  The  use  of  this  high-level  execution 
model  makes  it  possible  to  'see '  what  happens  dur¬ 
ing  execution  of  a  program.  For  example,  our  con¬ 
tour  model  can  illustrate  race  conditions  that  arise 
during  execution  of  programs,  the  effects  of  the 
definitions  of  task  dependence  and  termination  in 
Ada  on  inter-task  communication  and  synchroniza¬ 
tion,  and  the  interplay  between  these  definitions  and 
basic  run-time  storage  management  concerns. 

The  paper  provides  a  high-level  introduction  to  the 
contour  model  of  Ada  tasking  and  demonstrates  its 
use. 

Eckmann85 

Eckmann.  "INATEST.  an  Interactive  Environment 
for  Testing  Formal  Specifications."  ACM  Software 
Eng.  Notes  10, 4  (April  1985). 

(From  the  Introduction)  Because  the  cost  of  for¬ 
mally  verifying  large  software  systems  is  high  in 
both  dollars  and  time,  it  is  often  the  practice  to  for¬ 
mally  verify  only  critical  requirements.  For  ex¬ 
ample,  a  system  may  be  formally  verified  to  be  con¬ 
sistent  with  a  particular  security  model.  However, 
in  addition  to  these  formally  verified  critical  re¬ 
quirements,  most  systems  also  have  less  critical 
functional  requirements  that  must  be  satisfied.  .. 

During  ihe  pasi  twelve  months,  the  Reliable  Soft- 
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ware  Group  at  UCSB  has  concentrated  its  effort  on 
the  design  and  implementation  of  a  symbolic  execu¬ 
tion  tool  called  Inatest....  Inatest  is  an  interactive 
tool  for  testing  specifications  early  in  the  software 
lifecycle  to  determine  whether  the  functional  re¬ 
quirements  for  the  system  being  designed  can  be 
met.  It  provides  an  environment  with  various 
modes  of  operation  to  be  used  in  testing  formal 
specifications  written  in  Ina  Jo.,.. 

Eckmann89 

Eckmann,  S.T.  Ina  Flo  User  Guide.  Unisys  Corpo¬ 
ration,  Culver  City,  CA,  May  1989. 

(From  the  Introduction)  Ina  Flo  is  an  information 
flow  analysis  tool  built  into  the  Ina  Jo  specification 
language  processor.  Ina  Flo  partially  automates 
covert  channel  analysis  of  Ina  Jo  specifications. 
Coven  channel  analysis  is  any  method  for  finding, 
and  evaluating  the  consequences  of  covert  channels 
in  a  system. 

Eggert89 

Eggert,  P.,  Cooper,  D.  Eckmann,  S.,  J.  Gingerich, 
S.  Holtsberg,  N.  Kelem,  and  R.  Martin.  FDM  User 
Guide.  TM-8486/000/03,  Unisys  Corporation,  Cul¬ 
ver  City,  CA,  Sept.  1889. 

(From  Preface)  This  guide  is  for  the  users  of  the 
Unisys  Formal  Development  Methodology  (FDM). 
New  users  should  read  the  entire  guide  for  instruc¬ 
tions  about  how  to  use  FDM.  Experienced  users 
can  skip  to  the  last  part  of  Section  4,  which  de¬ 
scribes  the  changes  in  the  latest  FDM  version. 

Estrin86 

Estrin,  G.,  R.S  Fenchel,  R.R.  Razouk,  and  M.K. 
Vernon.  “SARA  (System  ARchitect’s  Apprentice): 
Modeling,  Analysis,  and  Simulation  Support  for  De¬ 
sign  of  Concurrent  Systems.”  IEEE  Trans.  Software 
Eng.  SE-I2,  2(1986),  293-311. 

Abstract :  An  environment  to  support  designers  in 
the  modeling,  analysis,  and  simulation  of  concur¬ 
rent  systems  is  described.  It  is  shown  how  a  fully 
nested  structure  model  supports  multilevel  design 
and  focuses  attention  on  the  interfaces  between  the 
modules  which  serve  to  encapsulate  behavior. 
Using  simple  examples,  the  paper  indicates  how  a 
formal  graph  model  can  be  used  to  model  behavior 
in  three  domains:  control  flow,  data  flow,  and  inter¬ 
pretation.  The  effectiveness  of  the  explicit  environ¬ 
ment  model  in  SARA  is  discussed  and  the  capability 
to  analyze  correctness  and  evaluate  performance  of 
a  system  model  are  demonstrated.  A  description  of 
the  integral  help  designed  into  SARA  shows  how  the 
designer  can  be  offered  consistent  use  of  any  new 
tool  introduced  to  support  the  design  process. 


Feather87 

Feather,  M.S.  “Language  Support  for  the  Specifica¬ 
tion  and  Development  of  Composite  Systems.”  ACM 
Trans.  Prog.  Lang,  and  Syst.  9,  2  (April  1987), 
198-234. 

Abstract:  When  a  complex  system  is  to  be  realized 
as  a  combination  of  interacting  components,  dev- 
lopement  of  those  components  should  commence 
from  a  specification  of  the  behavior  required  of  the 
composite  systems.  A  separate  specification  should 
be  used  to  describe  the  decomposition  of  that  system 
into  components.  The  first  phase  of  implementation 
from  a  specification  in  this  style  is  the  derivation  of 
the  individual  component  behaviors  implied  by 
these  specifications. 

The  virtues  of  this  apporach  to  specification  are  ex¬ 
pounded,  and  specification  language  features  that 
are  supportive  of  it  are  presented.  It  is  shown  how 
these  are  incorporated  in  the  specification  language 
Gist,  which  our  group  has  developed  These  issues 
are  illustrated  in  a  development  of  a  controller  for 
elevators  serving  passengers  in  a  multistory  build¬ 
ing. 

Feiertag79 

Feiertag,  R.  and  P.G.  Neumann.  “The  Foundations 
of  a  Provable  Secure  Operating  System  (PSOS).” 
National  Computer  Conference.  Montvale,  NJ: 
AFIPS,  1979,  329-334. 

(From  the  Introduction)  PSOS  has  been  designed 
according  to  a  set  of  formal  techniques  embodying 
the  SRI  Hierarchical  Development  Methodology 
(HDM).  HDM  has  been  described  elsewhere,  ... 
and  thus  is  only  summarized  here.  The  influence  of 
HDM  on  the  security  of  PSOS  is  also  discussed 
elsewhere....  In  addition.  Linden  ...  gives  a  general 
discussion  of  the  impact  of  structured  design  tech¬ 
niques  on  the  security  of  operating  systems 
(including  capability  systems). 

Feiertag80 

Feiertag,  R.J.  A  Technique  for  Proving  Specifica¬ 
tions  are  Multilevel  Secure.  CSL-109.  Computer 
Science  Laboratory,  SRI  International,  Menlo  Park, 
CA,  Jan.  1980. 

(From  the  Introduction)  The  following  sections  de¬ 
scribe  a  technique  for  verifying  that  a  design  for  an 
operating  system  expressed  in  terms  of  a  formal 
specification  is  consistent  with  a  particular  model  of 
multilevel  security.  The  technique  to  be  described 
is  mathematically  rigorous  and,  if  applied  properly, 
gives  assurance  that  the  given  design  is  multilevel 
secure  by  this  particular  model.  The  technique  is 
supported  by  a  collection  of  automated  tools. 
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Feldman90 

Feldman,  M.B.  Language  and  System  Support  for 
Concurrent  Programming.  Curriculum  Module 
SEI-CM-25,  DTIC:  ADA  223760,  Software  Engi¬ 
neering  Institute,  Carnegie  Mellon  University,  Pitts¬ 
burgh,  Pa.,  April  1990. 

(From  Capsule  Description)  This  curriculum  mod¬ 
ule  is  concerned  with  support  for  concurrent  pro¬ 
gramming  provided  to  the  application  programmer 
by  operating  systems  and  programming  languages. 
This  includes  system  calls  and  language  constructs 
for  process  creation,  termination,  synchronization, 
and  communication,  as  well  as  nondeterministic 
language  constructs  such  as  the  selective  wait  and 
timed  call.  Several  readily  available  languages  are 
discussed  and  compared;  concurrent  programming 
using  system  services  of  the  UNIX  operating  sys¬ 
tem  is  introduced  for  the  sake  of  comparison  and 
contrast. 

Francez80 

Francez,  N.,  D.J.  Lehmann,  and  A.  Pnueli.  “A 
Linear  History  Semantics  for  Distributed 
Languages.”  Twenty-First  Annual  Symposium  on 
Foundations  of  Computer  Science.  Long  Beach, 
CA:  IEEE  Computer  Society,  1980. 

Abstract:  A  denotational  semantics  is  given  for  a 
distributed  language  based  on  communication 
(CSP).  The  semantics  uses  linear  sequences  of 
communications  to  record  computations;  for  any 
well  formed  program  segment  the  semantics  is  a 
relation  between  attainable  states  and  the  communi¬ 
cation  sequences  needed  to  attain  these  states.  In 
binding  two  or  more  processes  we  match  and  merge 
the  communication  sequences  assumed  by  each 
process  to  obtain  a  sequence  and  state  of  the  com¬ 
bined  process.  The  approach  taken  here  is  distin¬ 
guished  by  relatively  simple  semantic  domains  and 
ordering. 

Gerhart79 

Gerhart,  S.L.  and  D.S.  Wile.  “Preliminary  Report  on 
the  Delta  Experiment.”  Specifications  of  Reliable 
Software.  Washington,  DC:  IEEE  Computer  Soci¬ 
ety,  April  1979,  198-211. 

Abstract:  The  1SI  Delta  Experiment  is  an  effort  to 
specify  and  verify  a  piece  of  real  software  of  moder¬ 
ate  complexity  and  size  (roughly  1000  lines).  This 
preliminary  report  describes :  ( l )  the  Delta  Junction, 
managing  the  editing  of  a  single  file  by  several 
users  within  an  operational  message  processing 
system;  (2)  the  formal  specification  of  the  Delta 
fimction  in  prose  and  in  algebraic  axioms;  (3)  the 
verification  methodology  in  levels  of  (a)  prose  for 
the  system  interface  level,  (b)  algebraic  axioms  for 
abstract  data  types,  (c)  recursive  functions  for 


major  operations,  (d)  implementation  of  the  recur¬ 
sive  functions  in  PASCAL  with  the  abstract  data 
types,  and  (e)  implementation  of  the  PASCAL  pro¬ 
grams  in  BLISS;  and  (4)  the  experience  gained  in 
this  experiment,  both  in  specification  and  verifica¬ 
tion. 

Ghezzi90 

Chezzi,  C.,  D.  Mandrioli,  and  A.  Morzenti.  “TRIO: 
A  Logic  Language  for  Executable  Specifications  of 
Real-Time  Systems.”  Journal  of  Systems  and  Soft¬ 
ware  12,  2  (Feb.  1990),  107-124. 

Abstract :  We  motivate  the  need  for  a  formal  speci¬ 
fication  language  for  real-time  applications  and  for 
a  support  environment  providing  tools  for  reason¬ 
ing  about  formal  specifications.  Then  we  intro¬ 
duced  TRIO,  a  logic-based  specification  language. 
TRIO  is  first  introduced  informally  through  ex¬ 
amples.  Then  a  formal  declarative  semantics  is 
provided,  which  can  accommodate  a  variety  of  un¬ 
derlying  time  structures.  Finally,  the  problem  of 
executing  TRIO  formal  specifications  is  discussed, 
and  a  solution  is  preseted. 

Ghezzi91 

Ghezzi,  C.  and  R.A.  Kemmerer.  “ASTRAL:  an 
Assertion  Language  for  Specifying  Realtime 
Systems.”  In  Proceedings  of  the  Third  European 
Software  Engineering  Conference,  ESEC  ’91.  Lec¬ 
ture  Notes  in  Computer  Science,  no.  550.  Berlin. 
Springer-Verlag,  1991. 

Abstract:  ASTRAL  is  a  formal  specification  lan¬ 
guage  for  realtime  systems.  This  paper  discusses 
the  rationale  of  ASTRAL’s  design  and  shows  how 
the  language  builds  on  previous  language  experi¬ 
ments.  ASTRAL  is  intended  to  support  formal  soft¬ 
ware  development;  therefore,  the  language  itself 
has  been  formally  defined.  ASTRAL 's  specification 
style  is  illustrated  by  discussing  a  case  study  taken 
from  telephony. 

Gold79 

Gold,  B.,  R.  Linde,  R.  Peeler,  M.  Schaefer, 
J.  Scheid,  and  P.  Ward.  “A  Security  Retrofit  of 
VM/370.”  National  Computer  Conference. 
Montvale,  NJ:  AFIPS,  1979,  335-344. 

(From  the  Introduction)  The  VM/370  Security 
Retrofit  Program  is  a  continuing  research  and  devel¬ 
opment  initiative,  funded  by  the  Defense  Advanced 
Research  Projects  Agency  (DARPA),  with  addition¬ 
al  funding  provided  by  Canadian  Department  of  Na¬ 
tional  Defense.  The  program's  primary  goal  is  the 
security  retrofit  of  a  popular  commercial  operating 
system,  VM/370.  Two  approaches  were  originally 
planned:  (1)  the  design  of  a  feasible,  formally  veri¬ 
fied  security  kernel  to  VM/370  and  (2)  a 
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“hardening"  effort  to  repair  known  VM/370 
penetration  weaknesses.  It  was  subsequently 
decided  not  to  proceed  with  the  VM/370  hardening 
task  because  of  the  uncertainty  of  the  end  result: 
correction  of  known  security  flaws  does  not 
guarantee  the  absence  of  exploitable,  but  not  yet 
detected,  security  flaws  in  the  hardened  system 

Goldschlag90a 

Goldschlag,  D.M.  “Mechanizing  Unity.”  In 
Programming  Concepts  and  Methods,  M.  Broy  and 
C.B.  Jones,  eds.  Amsterdam:  North-Holland,  1990, 
387-414. 

Abstract:  This  report  describes  a  mechanically  ver¬ 
ified  proof  system  for  concurrent  programs.  This 
proof  system  may  be  used  to  mechanically  verify  the 
correctness  proofs  of  concurrent  programs.  Me¬ 
chanical  verification  increases  the  trustworthiness 
of  a  prooof. 

This  proof  system  is  based  on  Unity  ....  but  is  de¬ 
fined  with  respect  to  an  operational  semantics  of  the 
transition  system  model  of  concurrency  ....  All 
proof  rules  are  justified  by  this  opeartional  seman¬ 
tics.  This  methodology  makes  a  clear  distinction 
between  the  theorems  in  the  proof  system  and  the 
logical  inference  rules  and  syntax  that  define  the 
underlying  logic.  Since  this  proof  system  essentially 
encodes  Unity  in  a  conservative  extension  of  anoth¬ 
er  sound  logic,  this  encoding  proves  the  soundness 
of  Unity. 

The  proof  system  has  been  implemented  on  the 
Boyer-Moore  p~  "er,  a  computer  program 
mechanizing  the  Boy^r-Moor  logic,...  and  has  been 
used  to  mechanically  verify  the  correctness  of  an 
n-processor  program  satisfying  both  mutual  exclu¬ 
sion  and  absence  of  starvation.  This  paper  also 
describes  this  program  and  its  correctness  theorems 
and  presents  the  key  lemmas  that  aided  the  mechan¬ 
ical  verification.  This  proof  closely  resembles  a 
Unity  hand  proof,  but  is  longer,  since  all  concepts 
are  defined  from  first  principles.  This  proof  system 
is  suiable  for  the  mechanical  verification  of  a  wide 
class  of  thoenns,  since  the  underlying  prover, 
though  automatic,  is  guided  by  the  user. 

Goldschlag90b 

Goldschlag,  D.M.  “Mechanically  Verifying  Concur¬ 
rent  Programs  with  the  Boyer-Moore  Prover.”  IEEE 
Trans.  Software  Eng.  16,  3  (Sept.  1990),  1005-1023. 

Abstract :  This  paper  describes  a  proof  system  suit¬ 
able  for  the  mechanical  verification  of  concurrent 
programs.  Mechanical  verification,  which  uses  a 
computer  program  to  validate  a  formal  proof,  in¬ 
creases  one 's  confidence  in  the  correctness  of  the 
validated  proof 

This  proof  system  is  based  on  Unity  ....  and  may  be 


used  to  specify  and  verify  both  safety  and  hveness 
properties.  However,  it  is  defined  with  respect  to 
an  operational  semantics  of  the  transition  system 
model  of  concurrency.  Proof  rules  are  simply 
theorems  of  this  operational  semantics.  This  meth¬ 
odology  makes  a  clear  distinction  between  the 
theorems  in  the  proof  system  and  the  logical  in¬ 
ference  rules  and  syntax  which  define  the  under¬ 
lying  logic.  Since  this  proof  system  essentially  en¬ 
codes  Unity  in  another  sound  logic,  and  this  encod¬ 
ing  has  been  mechanically  verified,  this  encoding 
proves  the  soundness  of  this  formalization  of  Unity. 

This  proof  system  has  been  mechanically  verified  by 
the  Boyer-Moore  prover,  a  computer  program 
mechanizing  the  Boyer-Moor  logic  ....  This  proof 
system  has  been  used  to  mechanically  verify  the 
correctness  of  a  distributed  algorithm  that  computes 
die  minimum  node  value  in  a  tree.  This  paper  also 
describes  this  algorithm  and  its  correctness 
theorems,  and  presents  the  key  lemmas  that  aided 
the  mechanical  verification.  The  mechanized  proof 
closely  resembles  a  hand  proof,  but  is  longer,  since 
all  concepts  are  defined  from  first  principles.  This 
proof  system  is  suitable  for  the  mechanical  verifi¬ 
cation  of  a  wide  class  of  programs,  since  the  under¬ 
lying  prover,  though  automatic,  is  guided  by  the 
user. 

Good78 

Good,  D.I.,  R.M.  Cohen,  C.G.  Hoch,  L.W.  Hunter, 
and  D.F.  Hare.  Report  on  the  Language  Gypsy,  Ver¬ 
sion  2.0.  ICSCA-CMP-10,  Institute  for  Computing 
Science,  University  of  Texas,  Austin,  TX,  Sept. 
1978. 

Good82 

Good,  D.I.,  A.E.  Siebert,  and  L.M.  Smith.  Message 
Flow  Modulator  Final  Report.  Report  No.  34,  Insti¬ 
tute  for  Computing  Science,  University  of  Texas, 
Austin,  TX,  Dec.  1982. 

Abstract:  The  message  flow  modulator  is  a  for¬ 
mally  specified  and  proved  filter  program  that  is 
applied  continuously  to  a  stream  of  messages  flow¬ 
ing  from  one  computer  system  to  another.  Mes¬ 
sages  that  pass  the  filter  are  passed  to  their  destina  ■ 
tion.  Messages  that  do  not  are  logged  on  an  audit 
trail.  The  modulator  has  been  designed  specifically 
to  monitor  the  flow  of  security >  sensitive  message 
traffic  from  the  Ocean  Surveillance  Information 
System  of  the  United  States  Naval  Electronic  Sys¬ 
tems  Command. 

The  modulator  has  been  designed,  specified,  and 
implemented  in  the  Gypsy  language.  All  of  the 
modules,  from  the  highest  level  of  design  to  the 
lowest  level  of  coding,  has  been  formally  specified 
and  mechanically  proved  with  the  Gypsy  Verifica¬ 
tion  Environment.  The  modulator  is  specifically  de- 
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signed  and  intended  for  use  in  actual  filed  opera¬ 
tion.  It  has  been  tested  in  a  simulated  operational 
environment  at  the  Patuxent  River  Naval  Air  Test 
Center  with  scenarios  developed  by  an  independent, 
external  group.  With  any  modification,  the  proved 
modulator  passed  all  of  these  tests  on  the  first  at¬ 
tempt. 

Good84a 

Good.  D.I.  Revised  Report  on  Gypsy  2.1,  Institute 
for  Computing  Science,  University  of  Texas,  Austin, 
TX,  March  1984. 

Abstract :  Gypsy  is  a  language  for  specifying,  im¬ 
plementing,  and  proving  computer  programs.  This 
document  is  the  revised  repon  on  Gypsy  2. 1.  Gypsy 
2. 1  includes  almost  all  of  Gypsy  2.0  with  some  ex¬ 
tensions  and  minor  modifications. 

Good84b 

Good,  D.I.,  B.L.  DiVito,  and  M.K.  Smith.  Using  the 
Gypsy  Methodology.  Draft  Technical  Report,  Insti¬ 
tute  for  Computing  Science,  University  of  Texas, 
Austin,  TX,  June  1984. 

Abstract:  This  report  describes  how  to  use  the 
Gypsy  methodology  for  designing  and  building  for¬ 
mally  verified  systems.  The  emphasis  is  on  tech¬ 
nique  and  examples. 

Guttag78 

Guttag,  J.V.,  E.  Horowitz,  and  D.R.  Musser. 
“Abstract  Data  Types  and  Software  Validation.” 
Comm.  ACM  21,  12  (Dec.  1978),  1048-1064. 

Abstract:  A  data  abstraction  can  be  naturally  spec¬ 
ified  using  algebraic  axioms.  The  virtue  of  these 
axioms  is  that  they  permit  a  representation- 
independent  formal  specification  of  a  data  type.  An 
example  is  given  which  shows  how  to  employ  al¬ 
gebraic  axioms  at  successive  levels  of  implemen¬ 
tation.  The  major  thrust  of  the  paper  is  twofold. 
First,  it  is  shown  how  the  use  of  algebraic 
axiomatizations  can  simplify  the  process  of  proving 
the  correctness  of  an  implementation  of  an  abstract 
data  type.  Second,  semi-automatic  tools  are  de¬ 
scribed  which  can  be  used  both  to  automate  such 
proofs  of  correctness  and  to  derive  an  immediate 
implementation  from  the  axioms.  This  implemen¬ 
tation  allows  for  limited  testing  of  programs  at  de¬ 
sign  time,  before  a  conventional  implementation  is 
accomplished. 

Hailpern82 

Hailpern,  B.  Verifying  Concurrent  Processes  Using 
Temporal  Logic.  Lecture  Notes  in  Computer  Sci¬ 
ence,  no.  129.  Berlin:  Springer- Verlag,  1982. 

(From  the  Introduction)  In  this  thesis  we  present  a 

62 


technique  for  proving  both  safety  and  liveness 
properties  of  parallel  programs.  Safety  properties 
are  assertions  that  must  be  satisfied  by  the  system 
stale  at  all  times;  they  arc  analogous  to  partial  cor¬ 
rectness.  Liveness  properties  refer  to  events  that 
will  occur  in  the  future,  such  as  program  termina¬ 
tion  or  the  eventual  execution  of  an  instruction  We 
describe  new  tools  for  verifying  programs  and 
heuristics  for  developing  proofs.  We  demonstrate 
the  applicability  of  the  technique  by  proving  the 
correctness  of  a  number  of  algorithms  from  the 
literature  in  the  areas  of  network  protocols  and 
resource  allocation.  The  spirit  of  this  thesis,  how¬ 
ever,  is  concerned  with  the  design  of  programs 

Harel88a 

Harel,  D.  “On  Visual  Formalisms,”  Comm.  ACM  31, 
5  (May  1988),  514-531. 

Abstract:  The  digraph,  a  general  kind  of  diagram¬ 
ming  object,  forms  a  visual  formalism  of  topologi¬ 
cal  nature.  Higraphs  are  suited  for  a  wide  array  of 
applications  to  databases,  knowledge  representa¬ 
tion,  and  most  notably,  the  behavioral  specification 
of  complex  concurrent  systems  using  the  higraph- 
based  language  of  statecharts. 

Harel88b 

Harel,  D.,  H.  Lachover,  A.  Naamad,  A.  Pnucli, 
M.  Poiili,  R.  Sherman,  and  A.  Shtul-Trauring. 
“STATEMATE:  A  Working  Environment  for  the 
Development  of  Complex  Reactive  Systems.”  10th 
International  Conference  on  Software  Engineering. 
Washington,  DC:  IEEE  Computer  Society,  1988, 
396-406. 

Abstract:  This  paper  provides  a  brief  overview  of 
the  STATEMATE  system,  constructed  over  the  past 
three  years  by  i-Logix  Inc.,  and  Ad  Cad  Ltd. 
STATEMATE  is  a  graphical  working  environment, 
intended  for  the  specification,  analysis,  design,  and 
documentation  of  large  and  complex  reactive  sys¬ 
tems,  such  as  real-time  embedded  systems,  control 
and  communication  systems,  and  interactive  soft¬ 
ware.  It  enables  a  user  to  prepare,  analyze  and 
debug  diagrammatic,  yet  precise,  descriptions  of  the 
system  under  development  from  three  inter-related 
points  of  view,  capturing,  structure,  functionality 
and  behavior.  These  views  are  represented  by  three 
graphical  languages,  the  most  intricate  of  which  is 
the  language  of  statecharts  used  to  depict  reactive 
behavior  over  time.  In  addition  to  the  use  of 
statecharts,  the  main  novelty  of  STATEMATE  is  in 
the  fact  that  it  'understands'  the  entire  descriptions 
(sicj  perfectly,  to  the  point  of  being  able  to  analyze 
them  for  crucial  dynamic  properties,  to  carry  out 
rigorous  animated  executions  and  simulations  of  the 
described  system,  and  to  create  running  code  auto¬ 
matically.  These  features  are  invaluable  when  it 
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comes  to  the  quality  and  reliability  of  the  final  out¬ 
come. 

Harrison88 

Harrison  L.J.  and  R.A.  Kemmerer.  “An  Interleaving 
Symbolic  Execution  Approach  For  the  Formal  Veri¬ 
fication  of  ADA  Programs  with  Tasking.” 
Proceedings  of  Third  International  IEEE  Con¬ 
ference  on  Ada  Applications  and  Environments. 
Washington,  DC:  IEEE  Computer  Society,  May 
1988, 15-26. 

Abstract:  There  have  been  several  efforts  to  use 
symbolic  execution  to  test  and  analyze  concurrent 
programs.  Recently  proof  systems  have  also 
emerged  for  concurrent  programs  and  for  the  Ada 
language  in  particular.  This  paper  focuses  on  using 
symbolic  execution  to  prove  partial  correctness  and 
general  safety  properties  of  Ada  programs.  It  ex¬ 
pands  upon  last  efforts  by  incorporating  tasking 
proof  rules  into  the  symbolic  executor  allowing  Ada 
programs  with  tasking  to  be  formally  verified. 

Haye$87 

Hayes,  I.,  ed.  Specification  Case  Studies. 
Englewood  Cliffs,  NJ:  Prentice-Hall,  1987. 

This  book  is  a  collected  set  of  case  studies  based  on 
the  use  of  Z,  providing  a  well-structured  introduc¬ 
tion  to  the  use  of  formal  methods.  The  section  on 
specification  of  the  UNIX  filing  system  may  in¬ 
volve  sufficiently  familiar  material  to  provide  a 
good  introduction  for  many  students.  It  is  suitable 
for  use  by  both  instructors  and  students. 

Hennessy88 

Hennessy,  M.  Algebraic  Theory  of  Processes.  Cam¬ 
bridge,  MA:  MIT  Press,  1988. 

This  book  starts  with  a  tutorial  about  a  language 
very  similar  to  CCS. 

Hinke83 

Hinke,  T„  J.  Althouse,  and  R.A.  Kemmerer.  “SDC 
Secure  Release  Terminal  Project.”  Proceedings  of 
the  1983  Symposium  on  Security  and  Privacy. 
Washington,  DC:  IEEE  Computer  Society,  April 
1983. 

Abstract:  The  SDC  Secure  Release  Terminal  (SRT) 
project  provides  a  useful  view  of  the  process  in¬ 
volved  in  constructing  software  whose  code  is  in¬ 
tended  to  be  formally  verified  to  satisfy  desired 
security  properties.  The  purpose  of  the  SRT  is  to 
move  appropriately  classified  data  from  a  process¬ 
ing  environment  at  one  security  level  to  a  process¬ 
ing  environment  at  another  level  in  machine  read¬ 
able  form. 


This  paper  discusses  the  design  process  for  the  SRT 
which  was  carried  out  using  the  SDC  Formal  De¬ 
velopment  Methodology  ( FDM ).  The  SRT  project  is 
the  first  application  of  the  FDM  code  level  verifi¬ 
cation  capabilities.  However,  since  the  code  level 
verification  has  not  yet  been  performed  this  paper 
concentrates  on  the  design  problems  inherent  in 
targeting  a  system  for  code  level  verification. 

Hoare69 

Hoare,  C.A.R.  “An  Axiomatic  Basis  for  Computer 

Programming.”  Comm.  ACM  12,  10  (Oct.  1969), 

576-580, 583. 

Abstract:  In  this  paper  an  attempt  is  made  to  ex¬ 
plore  the  logical  foundations  of  computer  program¬ 
ming  by  use  of  techniques  which  were  first  applied 
in  the  study  of  geometry  and  have  later  been  ex¬ 
tended  to  other  branches  of  mathematics.  This  in¬ 
volves  the  elucidation  of  sets  of  axioms  and  rules  of 
inference  which  can  be  used  in  proofs  of  the 
properties  of  computer  programs.  Examples  are 
given  of  such  axioms  and  ru  les,  and  a  formal  proof 
of  a  simple  theorem  is  displayed.  Finally,  it  is 
argued  that  important  advantages,  both  theoretical 
and  practical,  may  follow  from  a  pursuance  of  these 
topics. 

This  is  the  original  paper  on  Hoare's  method.  The 
important  theoretical  and  practical  advantages  al¬ 
luded  to  in  the  abstract  have  indeed  followed  from  a 
pursuance  of  the  topics  of  this  paper. 

Hoare78 

Hoare,  C.  “Communicating  Sequential  Processes" 

Comm.  ACM  21,  8  (Aug.  1978),  666-677. 

Abstract:  This  paper  suggests  that  input  and  output 
are  basic  primitives  of  programming  and  that 
parallel  composition  of  communicating  sequential 
processes  is  a  fundamental  program  structuring 
method.  When  combined  with  a  development  of 
Dijkstra's  guarded  command,  these  concepts  are 
surprisingly  versatile.  Their  use  is  illustrated  by 
sample  solutions  of  a  variety  of  familiar  program¬ 
ming  exercises. 

Hoare85 

Hoare,  C.A.R.  Communicating  Sequential 

Processes.  Englewood  Cliffs,  NJ:  Prentice-Hall, 

1984. 

This  book  is  the  definitive  book  explaining  lan¬ 
guage,  semantics,  and  the  use  of  CSP. 

Holtsberg89 

Holtsberg,  S.,  P.  Montgomery,  and  J.  Gingerich. 

FDM  Error  Message  Reference.  TM-8494/001/01, 

Unisys  Corporation,  Culver  City,  CA,  June  1989. 
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(From  Preface)  This  reference  is  for  users  of  the 
Unisys  Formal  Development  Methodology 
(FDM)....  The  purpose  of  this  document  is  to  pro¬ 
vide  a  reference  for  the  error  messages  generated  by 
Release  12.4  of  the  FDM  tools. 

Hopcroft79 

Hopcroft,  J.E.  and  J.D.  Ullman.  Introduction  to 
Automata  Theory,  Languages,  and  Computation. 
Reading,  MA:  Addison-Wesley,  1979. 

This  book  is  the  key  book  used  to  teach  formal  lan¬ 
guages  and  automata  theory. 

IS089 

International  Standards  Organization.  Information 
processing  systems  —  Open  Systems  Interconnec¬ 
tion  —  LOTOS  —  A  formal  description  technique 
based  on  the  temporal  ordering  of  observational 
behavior.  International  Standard  ISO  8807.  Swit¬ 
zerland:  International  Standards  Organization,  1989. 

This  is  the  defining  document  for  the  international 
standard  LOTOS  specification  language 

Karam91 

Karam,  G.M.  and  R.J.A.  Buhr.  “Temporal  Logic- 
Based  Deadlock  Analysis  for  Ada.”  IEEE  Trans. 
Software  Eng.  SE-I7,  10  (Oct.  1989),  1109-1125. 

Abstract:  This  paper  describes  an  [sic]  temporal 
logic-based  specification  language  and  deadlock 
analyzer  for  Ada.  The  deadlock  analyzer  (along 
with  other  analyzers)  are  intended  for  use  within 
TimeBench.  a  concurrent  system-design  environ¬ 
ment  with  support  for  Ada.  The  specification  lan¬ 
guage,  COL.  uses  linear  time  temporal  logic  to  pro¬ 
vide  a  formal  basis  for  axiomatic  reasoning.  The 
deadlock  analysis  tool  uses  the  reasoning  power  of 
COL  to  demonstrate  that  Ada  designs  specified  in 
COL  are  system-wide  deadlock-free:  in  essence,  it 
uses  a  specialized  theorem  prover  to  deduce  the  ab¬ 
sence  of  deadlock.  The  deadlock  algorithm  is 
shown  to  be  decidable  for  finite  systems  and  accept¬ 
able  otherwise:  it  is  also  shown  to  have  a  worst- 
case  computational  complexity  that  is  exponential 
with  the  number  of  tasks.  The  analyzer  has  been 
implemented  in  Prolog.  Numerous  examples  are 
evaluated  using  the  analyzer— the  examples  vary  in 
complexity  and  in  the  number  of  tasks:  readers  and 
writers,  gas  station,  five  dining  philosphers,  and  a 
layered  communications  system.  The  results  in¬ 
dicate  that  analysis  time  is  reasonable  for  moderate 
designs  in  spite  of  the  worst-case  complexity  of  the 
algorithm. 

Kemmerer82 

Kemmerer,  R.A.  Formal  Verification  of  an  Operat¬ 
ing  System  Security  Kernel.  Ann  Arbor,  MI:  UMI 
Research  Press,  1982. 

64 


Kemmerer83 

Kemmerer,  R.A.  and  S.T.  Eckmann.  A  User’s 
Manual  for  the  UNISEX  System.  TRCS83-05,  De¬ 
partment  of  Computer  Science,  University  of  Cali¬ 
fornia,  Santa  Barbara,  CA,  Dec.  1983. 

(From  the  Introduction)  UNISEX,  a  UNIx-based 
Symbolic  EXecutor  for  Pascal,  provides  an  environ¬ 
ment  for  testing  and  verification  of  programs. 

Kemmerer85 

Kemmerer,  R.A.  and  Eckmann,  S.T.  “UNISEX:  A 
UNIx-based  Symbolic  EXecutor  for  Pascal.” 
Software — Practice  and  Experience  15,  5  (May 
1985),  439-458. 

Abstract:  UNISEX  is  a  UNIX-based  symbolic  ex¬ 
ecutor  for  Pascal.  The  UNISEX  system  provides  an 
environment  for  both  testing  and  verifying  Pascal 
programs.  The  system  supports  a  large  subset  of 
Pascal,  runs  on  UNIX  and  provides  the  user  with  a 
variety  of  debugging  features  to  help  in  the  difficult 
task  of  program  validation.  This  paper  contains  a 
brief  introduction  to  symbolic  execution,  followed 
by  an  overview  if  the  features  of  UNISEX,  a  discus¬ 
sion  of  the  UNISEX  Pascal  language,  and  some  of 
the  implementation  details  for  the  UNISEX  system. 
Finally,  some  of  the  problems  encountered  when  de¬ 
signing  and  implementing  the  system  are  discussed 
as  well  as  future  directions. 

King80 

King,  J.C.  “Program  Correctness:  On  Inductive 
Assertion  Methods.”  IEEE  Trans.  Software  Eng. 
SE-6  (1980),  465-479. 

Abstract:  A  study  of  several  of  the  proof  of  correct¬ 
ness  methods  is  presented  In  particular,  the  form 
of  induction  used  is  explored  in  detail.  A  relational 
semantic  model  for  programming  languages  is  in¬ 
troduced  and  its  relation  to  predicate  transformers 
is  explored.  A  rather  elementary  viewpoint  is  taken 
in  order  to  expose,  as  simply  as  possible,  the  basic 
differences  of  the  methods  and  the  underlying  prin¬ 
ciples  involved.  These  results  were  obtained  by  at¬ 
tempting  to  thoroughly  understand  the  "subgoal 
induction  ”  method. 

Klein83 

Klein,  M.  Department  of  Defense  Trusted  Computer 
System  Evaluation  Criteria.  Fort  Meade,  MD:  De¬ 
partment  of  Defense,  1983. 

(From  Preface)  The  trusted  computer  system  evalu¬ 
ation  criteria  defined  in  this  document  classify  sys¬ 
tems  into  four  broad  hierarchical  divisions  of  en¬ 
hanced  security  protection.  They  provide  a  basis 
for  the  evaluation  of  effectiveness  of  security  con¬ 
trols  built  into  automatic  data  processing  system 
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products.  The  criteria  were  developed  with  three 
objectives  in  mind:  (a)  to  provide  users  with  a 
yardstick  with  which  to  assess  the  degree  of  trust 
that  can  be  placed  in  computer  systems  for  the 
secure  processing  of  classified  or  oilier  sensitive  in¬ 
formation;  (b)  to  provide  guidance  to  manufacturers 
as  to  what  to  build  into  their  new,  widely-available 
trusted  commercial  products  in  order  to  satisfy  trust 
requirements  for  sensitive  applications;  and  (c)  to 
provide  a  basis  for  specifying  security  requirements 
in  acquisition  specifications.  Two  types  of  require¬ 
ments  are  delineated  for  secure  processing:  (a)  spe¬ 
cific  security  feature  requirements  and  (b)  assurance 
requirements 

Lamport76 

Lamport,  L.  “The  Synchronization  of  Independent 

Processes.”  Acta  Informaiica  (5(1976),  15-34. 

Abstract:  This  paper  considers  the  problem  s  of 
programming  a  multiple  process  system  so  that  it 
continues  to  operate  despite  the  failure  of  individual 
processes.  A  powerful  synchronizing  primitive  is 
defined,  and  it  is  used  to  solve  some  sample  prob¬ 
lems.  An  algorithm  is  then  given  which  implements 
this  primitive  under  very  weak  assumptions  about 
the  nature  of  interprocess  coma. unication,  and  a 
careful  informal  proof  of  its  correctness  is  given. 

Lamport80a 

Lamport,  L.  “The  ‘Hoare  Logic’  of  Concurrent 

Programs.”  Acta  Information  14  (1980),  21-37. 

Abstract :  Hoare 's  logical  system  for  specify  ing  and 
proving  partial  correctness  properties  of  sequential 
programs  is  generalized  to  concurrent  programs. 
The  basic  idea  is  to  define  the  assertion  [P}k{Q\  to 
mean  that  if  execution  is  begun  anywhere  in  S  with 
P  true,  then  P  will  remain  true  until  S  terminates, 
and  Q  will  remain  true  if  and  when  S  terminates 
The  predicates  P  and  Q  may  depend  upon  program 
control  locations  as  well  as  upon  the  values  of  vari¬ 
ables.  A  system  of  inference  rules  and  axiom 
schemas  is  given,  and  a  form/,  correctness  proof 
for  a  simple  program  is  outlined.  We  show  that  by 
specifying  certain  requirements  for  the  unimple¬ 
mented  parts,  correctness  properties  can  be  proved 
without  completely  implementing  the  program.  The 
relation  to  Pnueli’s  temporal  logic  formalism  is 
also  discussed. 

Lamport80b 

Lamport,  L  “‘Sometime’  Is  Sometimes  'Not  Never’, 

On  (lie  Temporal  I.ogic  of  Programs."  Conference 

Record  Seventh  Annual  ACM  Symposium  on  Prin- 

<  iples  of  Programming  Languages.  New  York; 

ACM,  Jan.  1980,  174-184. 

(Prom  the  Introduction)  We  will  describe  two  dif¬ 


ferent  temporal  logics  for  reasoning  about  a  compu¬ 
tational  model.  The  same  formulas  appear  in  both 
logics,  but  (hey  are  interpreted  differently  The  two 
interpretations  correspond  to  two  ways  of  viewing 
time:  as  a  continually  branching  set  of  possibilities, 
or  as  a  single  linear  sequence  of  actual  events  Hie 
temporal  concepts  of  "sometime"  and  “not  never" 
("not  always  not")  are  equivalent  in  the  theory  of 
linear  time,  but  not  in  die  theory  of  branching  time 
—  hence,  our  title.  We  wilt  argue  that  the  logic  of 
linear  time  is  better  for  reasoning  about  concurrent 
programs,  and  the  logic  of  branching  tune  is  better 
for  reasoning  about  nondetermimstic  programs 

Lamport  83a 

I  amport,  L.  “Specifying  Concurrent  Program 
Modules."  ACM  Trans.  Prog.  L  '<g.  and  S\st.  5,  2 
(Feb.  1983),  190-222. 

Abstract:  A  method  for  specify  ing  program  mod¬ 
ules  in  a  concurrent  program  is  described  It  is 
based  upon  temporal  logic,  but  it  uses  new  kinds  of 
temporal  assertions  to  make  the  specification * 
simpler  and  easier  to  understand  The  semantics  of 
the  specifications  is  describe u  informally,  and  a  se¬ 
quence  of  examples  are  given  culminatin'’  in  a  spec¬ 
ification  of  three  modules  comprising  the 
alternating-bit  communication  protocol  A  formal 
semantics  is  given  in  the  appendix. 

Lamport83b 

I, amport,  L.  “What  Good  is  Temporal  Logic?”  In 
Information  Processing  83.  R.K.A.  Mason,  tel 
Amsterdam:  North-Holland,  1983,  657-667. 

Abstract:  Temporal  Logic  is  a  formal  system  for 
specifying  and  reasoning  about  concurrent  pro¬ 
grams.  It  provides  a  uniform  framework  for  de¬ 
scribing  a  system  at  any  level  of  abstraction, 
thereby  supporting  Hierarchical  specification  and 
verification. 

Lamport84 

Lamport,  L  "What  it  Means  for  a  Concurrent  Pro¬ 
gram  to  Satisfy  a  Specification:  Why  No  One  Has 
Specified  Priority."  Conference  Record  Twelfth  An¬ 
nual  ACM  Symposium  on  Principles  of  Program¬ 
ming  Languages.  New  York.  ACM,  Jan.  1985. 
78-83. 

Abstract:  The  formal  correspondence  between  an 
implementation  and  its  specification  is  examined.  It 
is  shown  that  existing  specifications  that  chum  to 
describe  priority  are  either  vacuous  or  else  too  re¬ 
strictive  to  be  implemented  in  some  reasonable 
situations.  This  is  illustrated  with  a  precisely  for¬ 
mulated  problem  of  specifying  a  first-come -first- 
served  mutual  exclusion  algorithm,  which  it  is 
claimed  cannot  be  solved  by  existing  methods. 
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Lamport86 

Lamport,  L.  A  Simple  Approach  To  Specifying  Con¬ 
current  Systems.  Technical  Report  15,  Digital  Sys¬ 
tems  Research  Center,  Palo  Alto,  CA,  1986. 

Abstract:  In  the  transition  axiom  method,  safety 
properties  of  a  concurrent  system  can  be  specified 
by  programs:  liveness  properties  are  specified  by 
assertions  in  a  simple  temporal  logic.  The  method 
is  described  with  some  simple  examples,  and  its 
logical  foundation  is  informally  explored  through  a 
careful  examination  of  what  it  means  to  implement 
a  specification.  Language  issues  and  ether  prac¬ 
tical  details  are  largely  ignored. 

Lamport87 

Lamport,  L.  win  and  sin:  Predicate  Transformers  for 
Concurrency.  Technical  Report  17,  Digital  Sy  terns 
Research  Center,  Palo  Alto,  CA,  May  1987. 

Abstract:  Dijkstra's  weakest  liberal  precondition 
and  strongest  postcondition  predicate  transformers 
are  generalized  to  the  weakest  invariant  and 
strongest  invariant  These  new  predicate  trans¬ 
formers  are  useful  for  reasoning  about  concurrent 
programs  containing  operations  in  which  the  grain 
of  atomicity  is  unspecified,  they  can  also  be  used  to 
replace  behavioral  arguments  with  more  rigorous 
assertional  ones. 

Landwehr81 

Landwehr,  C.E.  “Formal  Models  for  Computer 
Security."  ACM  Computing  Surveys  13,  3  (Sept. 
1981),  247-278. 

Abstract:  Efforts  to  build  "secure"  computer  sys¬ 
tems  have  now  been  underway  for  more  than  a 
decade.  Many  designs  have  been  proposed,  some 
prototypes  have  been  constructed,  and  a  few  sys¬ 
tems  are  approaching  the  production  stage.  A 
small  number  of  systems  are  even  operating  in  what 
the  Department  of  Defense  calls  "multilever  mode: 
some  information  contained  in  these  computer  sys¬ 
tems  may  even  have  a  classification  higher  than  the 
clearance  of  some  of  the  users  of  those  systems. 

This  paper  reviews  the  need  for  formal  security 
models,  describes  the  structure  and  operation  of 
military  security  controls,  considers  how  automa¬ 
tion  has  affected  security  problems,  surveys  models 
that  have  been  proposed  and  applied  to  date,  and 
suggests  possible  directions  for  future  models. 

Landwehr83 

Landwehr,  C.  “The  Best  Available  Technologies  for 
Computer  Security.”  Computer  16,  7  (July  1983). 

Abstract:  This  concise  overview  of  secure  system 
developments  summarizes  past  and  current  projects, 
deciphers  computer  security  lingo,  and  offers  ad¬ 
vice  to  prospective  designers. 


Lee81 

S.  Lee  and  S.L.  Gerhart.  AFFIRM  User's  Guide. 
USC  Information  Sciences  Institute,  Marina  del  Rey, 
CA,  Feb.  1981. 

(From  Preface)  The  AFFIRM  USER  S  GUIDE  ac¬ 
companies  the  AFFIRM  REFERENCE  MANUAL 
and  the  AFFIRM  TYPE  LIBRARY  in  order  to  make 
life  easier  for  people  who  really  want  to  use 
AFFIRM  The  GUIDE  is  a  distillation  of  experi¬ 
ence  by  the  PV  project  (and  others)  which  we  want 
to  pass  on  to  users. 

Leveson83 

Leveson,  N.G.,  A.l  Wasserman,  and  D  M  Berry. 
“BASIS:  A  Behavioral  Approach  to  the  Specifica¬ 
tion  of  Information  Systems"  Information  Sciences 
8,  1  (1983),  15-23. 

Abstract:  This  paper  is  an  overview  of  BASIS 
(Behavioral  Approach  to  the  Specification  of  Infor¬ 
mation  Systems),  a  multi-step  formal  method  used 
for  information  systems  design  and  development. 
The  steps  include  information  analysis,  semantic 
specification,  verification  of  the  specification,  con¬ 
crete  implementation,  and  verification  of  the  imple¬ 
mentation.  In  this  wav,  BASIS  can  be  used  to  pro¬ 
vide  a  formal  basis  for  information  systems  devel¬ 
opment.  We  provide  an  example  showing  how  BAS¬ 
IS  can  be  used  in  conjunction  with  implementation 
in  the  programming  language  PLAIN 

Leveson9l 

Leveson,  N.G.,  M.  Heimdahl,  H.  Hildreth.  J.  Reese, 
and  R.  Onega.  “Experiences  using  Stalecharts  for  a 
System  Requirements  Specification."  Sixth  Interna¬ 
tional  Workshop  on  Software  Specification  and 
Design.  Washington,  DC.  IEEE  Computer  Society, 
1991,31-41. 

Abstract:  This  paper  describes  some  lessons 

learned  and  issues  raised  while  building  a  system 
requirements  specification  for  a  real  aircraft  col¬ 
lision  avoidance  system  using  stalecharts.  Some  en¬ 
hancements  to  statecharts  were  necessary  to  model 
the  complete  system  and  a  few  notational  changes 
were  made  to  improve  reviewability. 

Levitt85 

Levitt,  K.N.  Communications  Network  in  Revised 
SPECIAL  Computer  Science  Laboratory,  SRI  Inter¬ 
national,  Menlo  Park,  CA,  June  1985. 

Lindsay88 

Lindsay,  P.A.  “A  Survey  of  Mechanical  Support  for 
Formal  Reasoning.”  Software  Engineering  Journal  3 
(1988),  3-27. 
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This  survey  examines  seven  support  systems  in  de¬ 
tail  and  introduces  eleven  others.  The  systems  dis¬ 
cussed  in  detail  are  LCF  (Logic  for  Computable 
Functions),  NuPRL,  Veritas,  Isabelle,  AFFIRM,  the 
Boyer-Moore  system,  and  Gypsy.  The  bibliography 
contains  87  items. 

Liskov74 

Liskov,  B.H.  and  S.N.  Zilles.  “Programming  with 
Abstract  Data  Types.”  ACM  S/GPLAN  Notices  9,  4 
(April  1974),  50-60. 

Abstract:  The  motivation  behind  this  work  in  very- 
high-level  languages  is  to  ease  the  programming 
task  by  providing  the  programmer  with  a  language 
containing  primitives  or  abstractions  suitable  to  his 
problem  area.  The  programmer  is  then  able  to 
spend  his  effort  in  the  right  place;  he  concentrates 
on  solving  his  problem,  and  the  resulting  program 
will  be  more  reliable  as  a  result.  Clearly,  this  is  a 
worthwhile  goat. 

Unfortunately,  it  is  very  difficult  for  a  designer  to 
select  in  advance  all  the  abstractions  which  the 
users  of  his  language  might  need.  If  a  language  is 
to  be  used  at  all,  it  is  likely  to  be  used  to  solve 
problems  which  its  designers  did  not  envision,  and 
for  which  the  abstractions  embedded  in  the  lan¬ 
guage  are  not  sufficient. 

This  paper  presents  an  approach  which  allows  the 
set  of  built-in  abstractions  to  be  augmented  when 
the  need  for  a  new  data  abstraction  is  discovered 
This  approach  to  the  handling  of  abstractions  is  an 
outgrowth  of  work  on  designing  a  language  for 
structured  programming.  Relevant  aspects  of  this 
language  are  described,  and  examples  of  the  use 
and  definitions  of  abstractions  are  given. 

Locas$o80 

Locasso,  R.,  J.  Scheid,  D.V.  Schorre,  and  P.R.  Eg- 
gert.  The  Ina  Jo  Reference  Manual. 
TM-(L)-602I/00 1/000,  System  Development  Corpo¬ 
ration,  Santa  Monica,  CA,  June  1980. 

Abstract:  The  Ina  Jo  specification  language  is  in 
use  at  SDC  as  part  of  its  formal  development  meth¬ 
od.  System  specifications  written  in  Ina  Jo  lan¬ 
guage  are  verified  mechanically  with  respect  to 
user-defined  criteria.  An  Ina  Jo  specification  is  a 
collection  of  levels:  each  level  describes  an  abstract 
machine  by  describing  its  states  and  possible  state 
transitions.  Lower  levels  contain  mappings  de¬ 
scribing  how  they  are  intended  to  implement  parts 
of  higher  levels.  The  top  level  cor. tains  correctness 
requirements  that  must  be  met  by  the  entire  system. 
Thus  an  Ina  Jo  specification  allows  for  a  structured 
proof  of  the  desired  properties  of  a  complete  sys¬ 
tem. 


Lucas69 

Lucas,  P.  and  K.  Walk.  "On  the  Formal  Description 
of  PL/I.”  Annual  Review  in  Automatic  Programming 
6,  3(1969). 

(From  the  Introduction)  This  paper  presents  tools 
and  design  criteria  for  the  formal  descnption  of  pro¬ 
gramming  languages.  The  results  reported  were 
achieved  mainly  during  the  development  of  the  for¬ 
mal  definition  of  PL/I  as  documented  in  a  series  of 
Technical  Reports  [from  IBM  Vienna  Laboratories). 

An  appropriately  tailored  subset  of  PL/1  is  used  to 
illustrate  these  results.  Their  applicability  is,  how¬ 
ever,  not  restricted  to  PL/1 

Luckham86 

Luckham,  D.C.,  D.P.  Helmbold,  S.  Meidal,  D.L. 
Bryan,  and  M.A.  Haberler.  “Task  Sequencing  Lan¬ 
guage  for  Specifying  Distributed  Ada  Systems.”  In 
System  Development  and  Ada:  CRAI  Workshop  on 
Software  Factories  and  Ada.  Lecture  Notes  in  Com¬ 
puter  Science,  no.  275.  Berlin:  Springer-Verlag, 
1986. 

Abstract:  TSL-1  is  a  language  for  specifying  se¬ 
quences  of  tasking  events  occuring  in  the  execution 
of  distributed  Ada  programs.  Such  specifications 
are  intended  primarily  for  testing  and  debugging  of 
Ada  tasking  programs,  although  they  can  also  be 
applied  in  designing  programs.  TSL-1  specifica¬ 
tions  are  included  in  an  Ada  program  as  formal 
comments.  They  express  constraints  to  be  satisfied 
by  the  sequences  of  acutal  tasking  events.  An  Ada 
program  is  consistent  with  its  TSL-1  specifications 
if  its  runtime  behavior  always  satisfies  them.  This 
paper  presents  an  overview  of  TSL-I.  The  features 
of  the  language  are  described  informally:  and  ex¬ 
amples  illustrating  the  use  of  TSL-1,  both  for  de¬ 
bugging  and  for  specification  of  tasking  programs, 
are  given.  A  definition  of  robust  TSL-1  specifica¬ 
tions  that  takes  into  account  uncertainty  in  runtime 
observation  of  behavior  of  distributed  systems  is 
given.  A  runtime  monitor  for  checking  consistency 
of  an  Ada  program  with  TSL-I  specifications  has 
been  implemented.  In  the  future,  constructs  for  de¬ 
fining  abstract  tasks  will  be  added  to  TSL-I.  form¬ 
ing  a  new  languages,  TSL-2,  for  the  specification  of 
distributed  systems  prior  to  their  implementation  in 
any  particular  programming  language. 

Manna72 

Manna,  Z„  S.  Ness,  and  J.  Vuillemin.  “Inductive 
Methods  for  Proving  Properties  of  Programs.”  ACM 
SIGPLAN  Notices  7,  1  (Jan.  1972),  27-50. 

Abstract:  We  have  two  main  purposes  in  this 
paper.  First,  we  clarify  and  extend  known  results 
about  computation  of  recursive  programs,  empha¬ 
sizing  the  difference  between  the  theoretical  ami 
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practical  approaches.  Secondly,  we  present  and  ex¬ 
amine  various  methods  for  proving  properties  of 
recursive  programs.  We  discuss  in  detail  two 
powerful  inductive  methods,  computational  induc¬ 
tion  and  structural  induction,  illustrating  their  ap¬ 
plications  by  various  examples.  We  also  briefly  dis¬ 
cuss  some  other  related  methods. 

Our  aim  in  this  work  is  to  introduce  inductive  meth¬ 
ods  to  as  wide  a  class  of  readers  as  possible  and  to 
demonstrate  their  power  as  practical  techniques. 

We  ask  the  forgiveness  of  our  more  theoretical- 
minded  colleagues  for  our  occasional  choice  of 
clarity  over  precision. 

Manna74 

Manna,  Z.  Mathematical  Theory  of  Computation. 
New  York:  McGraw-Hill,  1974. 

The  book  has  a  wide-ranging  survey  of  topics  in  the 
theory  of  computation.  Chapter  3  deals  with  verifi¬ 
cation  of  program  correctness  and  halting. 

Manna81 

Manna,  Z.  and  A.  Pnueli.  “Verification  of  Concur¬ 
rent  Programs:  The  Temporal  Framework.”  In  The 
Correctness  Problem  in  Computer  Science,  R.S. 
Boyer  and  J.S.  Moore,  eds.  London:  Academic 
Press,  1981,215-273. 

Abstract :  This  is  the  first  in  a  series  of  reports 
describing  the  application  of  Temporal  Logic  to  the 
specification  and  verification  of  concurrent  pro¬ 
grams. 

We  first  introduce  Temporal  Logic  as  a  tool  for 
reasoning  about  sequences  of  slates.  Models  of 
concurrent  programs  based  both  on  transition 
graphs  and  on  linear-text  representations  are 
presented  and  the  notions  of  concurrent  and  fair 
executions  are  defined 

The  general  temporal  language  is  then  specialized 
to  reason  about  those  execution  states  and  execu¬ 
tion  sequences  that  are  fair  computations  of  concur¬ 
rent  programs.  Subsequently,  the  language  is  used 
to  describe  properties  of  concurrent  programs. 

The  set  of  interesting  properties  is  classified  into 
Invariance  (Safety),  Eventuality  (Liveness)  and 
Precedence  (Until)  properties.  Among  the 
properties  studied  are:  Partial  Correctness.  Global 
Invariance,  Clean  Behavior,  Mutual  Exclusion, 
Deadlock  Absence,  Termination,  Total  Correctness, 
Intermittent  Assertions,  Accessibility ,  Starvation 
Freedom ,  Responsiveness,  Safe  Liveness,  Absence 
of  Unsolicited  Response,  Fair  Responsiveness  and 
Precedence. 

In  the  following  reports  of  this  series  we  use  the 
temporal  formalism  to  develop  proof  methodologies 
for  proving  the  properties  discussed  here. 
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McCarthy65 

McCarthy,  J.,  P.W.  Abrahams,  D.J.  Edwards,  T.P. 
Hart,  and  M.  Levin.  LISP  1.5  Programmer's 
Manual.  Cambridge,  MA:  MIT  Press,  1965. 

This  book  is  the  original  LISP  manual.  It  contains  a 
definition  of  LISP  written  in  LISP. 

McCauley79 

McCauley.  E.  and  P.  Drongowski.  ‘‘KSOS  —  The 
Design  of  a  Secure  Operating  System.”  National 
Computer  Conference.  Montvale,  NJ:  AFIPS,  1979, 
345-353. 

(From  the  Introduction)  This  paper  discusses  the  de¬ 
sign  of  the  Department  of  Defense  (DoD)  Kemel- 
ized  Secure  Operating  System  (KSOS,  formerly 
called  Secure  UNIX).  KSOS  is  intended  to  provide 
a  provably  secure  operating  system  for  larger  min¬ 
icomputers,  KSOS  will  provide  a  system  interface 
closely  compatible  with  the  UNIX  operating  sys¬ 
tem.  The  initial  implementation  of  KSOS  will  be 
on  a  Digital  Equipment  Corporation  PDP-11/70 
computer  system.  A  group  from  Honeywell  is  also 
proceeding  with  an  implementation  for  a  modified 
version  of  the  Honeywell  Level  6  computer  system. 

McGowan71 

McGowan,  C.L.  “An  Inductive  Proof  Technique  for 
Interpreter  Correctness.”  In  Courant  Computer  Sci¬ 
ence  Symposium  on  Format  Semantics  of  Program¬ 
ming  Languages,  R.  Rustin,  ed.  Englewood  Cliffs, 
NJ:  Prentice-Hall,  1971. 

Abstract:  A  general  inductive  /  oof  technique  is 
presented  which  has  been  successfidly  used  in  es¬ 
tablishing  the  correctness  and  equivalence  of  inter¬ 
preters  for  the  lambda  calculus  and  for  block  struc¬ 
tured  languages. 

Meadows88 

Meadows,  C.A.  A  Method  for  Automatically  Trans¬ 
lating  Trace  Specification  into  Prolog.  NRL9131, 
Naval  Research  Laboratory,  1988. 

MilnerSO 

Milner,  R.  A  Calculus  of  Communicating  Systems. 
Lecture  Notes  in  Computer  Science,  no.  92.  Berlin: 
Springer- Verlag,  1980. 

This  book  is  the  definitive  book  defining  CCS. 

Milner89 

Milner,  R.  Communication  and  Concurrency. 
Englewood  Cliffs,  NJ.  Prentice-Hall,  1989. 

This  book  is  the  definitive  book  explaining  and  de¬ 
fining  CCS.  It  is  significantly  more  tutorial  than  the 
other  book  by  the  same  author  in  1980. 
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Moore90 

Moore,  A.P.  “The  Specification  and  Verified 
Decomposition  of  System  Requirements  Using 
CSP.”  IEEE  Trans.  Software  Eng.  16,  3  (Sept. 
1990),  933-948. 

Abstract:  An  important  principle  of  building 

trustworthy  systems  is  to  rigorously  analyze  the  cri¬ 
tical  requirements  early  in  the  development  process, 
even  before  starting  system  design.  Existing  proof 
methods  for  systems  of  communicating  processes 
focus  on  the  bottom-up  composition  of  component- 
level  specifications  into  system-level  specifications. 
Trustworthy  system  development  requires,  instead, 
the  top-down  derivation  of  component  requirements 
from  the  critical  system  requirements.  This  paper 
describes  a  formal  method  for  decomposing  the  re¬ 
quirements  of  a  system  into  requirements  of  its  com¬ 
ponent  processes  and  a  minimal,  possibly  empty,  set 
of  synchronization  requirements.  The  Trace  Model 
of  Hoare’s  Communicating  Sequential  Processes 
( CSP)  is  the  basis  for  the  formal  method.  We  apply 
the  method  to  an  abstract  voice  transmitter  and  de¬ 
scribe  the  role  that  the  EHDM  verification  system 
plays  in  the  transmitter's  decomposition.  In  combi¬ 
nation  with  other  verification  techniques,  we  expect 
that  the  method  defined  here  will  promote  the  devel¬ 
opment  of  more  trustworthy  systems. 

Morgan87 

Morgan,  K.T.  and  R.R.  Razouk.  “Interactive  State- 
Space  Analysis  of  Concurrent  Systems.”  IEEE 
Trans.  Software  Eng.  SE-I3,  10  (Oct.  1987), 
1080-1091. 

Abstract:  The  introduction  of  concurrency  into 
programs  has  added  to  the  complexity  of  the  soft¬ 
ware  design  process.  This  is  most  evident  in  the 
design  of  communications  protocols  where  concur¬ 
rency  is  inherent  to  the  behavior  of  the  system.  The 
complexity  exhibited  by  such  software  systems 
makes  more  evident  the  need  for  computer-aided 
tools  for  automatically  analyzing  behavior. 

The  Distributed  Systems  project  at  UCI  has  been 
developing  techniques  and  tools,  based  on  Petri 
nets,  which  support  the  design  and  evaluation  of 
concurrent  software  systems.  Techniques  based  on 
constructing  reachability  graphs  that  represent 
projections  and  selections  of  complete  state-spaces 
have  been  developed.  This  paper  focuses  attention 
on  the  computer-aided  analysis  of  these  graphs  for 
the  purpose  of  proving  correctness  of  the  modeled 
system.  Die  application  of  the  analysis  technique  to 
evaluating  simulation  results  for  correctness  is  dis¬ 
cussed.  The  tool  which  supports  this  analysis  (the 
reachability  graph  analyzer,  RGA)  is  also  de¬ 
scribed  This  tool  provides  mechanisms  for  proving 
general  system  properties  (e.g.,  deadlock-freeness ) 
as  well  as  system-specific  properties.  The  tool  is 
sufficiently  general  to  allow  a  user  to  apply  complex 


user-defined  analysis  algorithms  to  reachability 
graphs.  The  alternating-bit  protocol,  with  a 
bounded  channel,  is  used  to  demonstrate  the  power 
of  the  tool  and  to  point  to  future  extensioi,s 

Musser85a 

Musser,  D.R.  and  D.A.  Cyrluk.  AFFIRM-S5  Instal¬ 
lation  Guide  and  Reference  Manual  Update.  Gen¬ 
eral  Dlcciric  Corporate  Research  and  Development, 
Schenectady,  NY,  March  1985. 

Musser85b 

Musser,  D.R.  “Aids  to  Hierarchical  Specification 
Structuring  and  Reusing  Theorems  in  Affirm-85 .” 
ACM  Software  Eng.  Notes  10, 4  (1985). 

(From  the  Introduction)  The  APTTRM  Program 
Verification  System  originated  at  the  University  of 
Southern  California  Information  Sciences  Institute 
(IS1).  It  is  an  experimental  system  for  the  algebraic 
specification  and  verification  of  abstract  data  types 
and  Pascal-like  programs  using  these  types... 
AFFIRM-85  is  an  enhanced  version  of  AFFIRM 
that  is  being  developed  at  General  Electric  Corpo¬ 
rate  Research  and  Development  Center  (GE-CRD). 
This  paper  briefly  describes  the  two  major  exten¬ 
sions  that  will  completed  in  early  in  1985  The 
primary  purpose  of  these  and  several  minor  exten¬ 
sions  is  to  enable  the  use  of  AFFIRM  in  carrying 
out  a  larger  part  of  the  software  development  proc¬ 
ess  than  previously  has  been  possible. 

Neumann77 

Neumann,  P.G.,  R.S.  Boyer.  R.J.  Feiertag,  and  K.N. 
Levitt.  A  Provably  Secure  Operating  System:  The 
System,  Its  Applications,  and  Proofs.  Final  Report, 
Computer  Science  Laboratory,  SRI  International, 
Menlo  Park,  CA,  Feb.  1977. 

Abstract:  This  report  provides  a  detailed  descrip¬ 
tion  of  the  design  of  a  secure  operating  system  and 
some  of  its  applications,  along  with  proofs  of  some 
of  the  properties  related  to  security.  Discussed  here 
are: 

•  a  formal  methodology  for  the  design  and 
implementation  of  computer  operating  sys¬ 
tems  and  application  subsystems,  and  for 
the  formal  proof  of  properties  of  such  sys¬ 
tems,  with  respect  to  both  the  design  and 
the  implementation; 

•  the  design  of  a  secure  capability-based 
operating  system  according  to  this  meth¬ 
odology  to  meet  advanced  security  re¬ 
quirements,  together  with  relevant  imple¬ 
mentation  considerations: 

•  the  design  of  several  application  subsys¬ 
tems  for  this  operating  system,  including 
support  for  multilevel  security  classifica- 
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lions,  for  confined  subsystems,  for  a  secure 
relational  data  management  system,  and 
for  monitoring  of  security; 

•  the  statement  and  proof  of  properties  of 
the  design  for  the  operating  system  and  for 
certain  application  subsystems; 

•  an  evaluation  of  the  significance  of  this 
work,  and  considerations  for  the  future  de¬ 
velopment  of  secure  systems  and  subsys¬ 
tems. 

Nguyen84 

Nguyen,  V.,  D.  Gries,  and  S.  Owieki.  “A  Model  for 
Temporal  Proof  System  for  Networks  of  Process,” 
Conference  Record  Twelfth  Annual  ACM  Sym¬ 
posium  on  Principles  of  Programming  Languages. 
New  York:  ACM,  Jan.  1985,  121-131. 

Abstract:  A  model  and  a  sound  and  complete  proof 
system  for  networks  of  processes  in  which  compo¬ 
nent  processes  communicate  exclusively  through 
messages  is  given.  The  model,  an  extension  of  the 
trace  model,  can  describe  both  synchronous  and 
asynchronous  networks.  The  proof  system  uses 
temporal-logic  assertions  on  sequences  of  obser¬ 
vations — a  generalization  of  traces.  The  use  of  ob¬ 
servations  (traces)  makes  the  proof  system  simple, 
compositional  and  modular,  since  internal  details 
can  be  hidden.  The  expressive  power  of  temporal 
logic  makes  it  possible  to  prove  temporal  properties 
(safety,  liveness,  precedence,  etc.)  in  the  system. 
The  proof  system  is  language-independent  and 
works  for  both  synchronous  and  asynchronous  net¬ 
works. 

Nie!sen89 

Nielsen,  M„  K.  Havelund,  K.R.  Wagner,  and 
C.  George.  "The  RAISE  Language,  Method  and 
Tools.”  Formal  Aspects  of  Computing  1,  1  (1989), 
85-114. 

Abstract:  This  paper  presents  the  RAISE  software 
development  method,  its  associated  specification 
language,  and  the  tools  supporting  it,  The  RAISE 
method  enables  the  stepwise  development  of  both 
sequential  and  conccurrent  software  from  abstract 
specification  through  design  to  implementation.  All 
stages  of  RAISE  software  development  are  ex¬ 
pressed  in  the  wide-spectrum  RAISE  specification 
language.  The  RAISE  tools  form  an  integrated  tool 
environment  supporting  both  language  and  method. 

The  paper  surveys  RAISE  and  furthermore,  more 
detailed  presentations  of  major  RAISE  results  are 
provided.  The  subjects  of  these  are  (a)  an  example 
of  the  use  of  the  RAISE  method  and  language,  and 
(b)  a  presentation  of  the  mathematical  semantics  of 
the  RAISE  specification  language. 


Organick72 

Organick,  E.I.  The  Multics  System.  Cambridge,  MA: 

MIT  Press,  1972. 

This  book  examines  the  structure  of  the  MIT  mul¬ 
tics  system  from  the  bottom  upwards. 

Organick78 

Organick,  E.I.,  A.l.  Forsythe,  and  R.P.  Plummer. 

Programming  Language  Structures.  New  York, 

NY:  Academic  Press,  1978. 

This  book  uses  Johnston’s  Contour  Model,  a  pic¬ 
torial  information  structure  model  to  describe  a 
variety  of  programming  languages  and  their  fea¬ 
tures. 

Owicki76a 

Owieki,  S.  and  D.  Gries.  “Verifying  Properties  of 

Parallel  Programs:  An  Axiomatic  Approach.” 

Comm.  ACM  19, 5  (May  1976),  279-285. 

Abstract:  An  axiomatic  method  for  proving  a  num¬ 
ber  of  properties  of  parallel  programs  is  presented. 
Hoare  has  given  a  set  of  axioms  for  partial  correct¬ 
ness,  but  they  are  not  strong  enough  in  most  cases. 
This  paper  defines  a  more  powerful  deductive  sys¬ 
tem  which  is  in  some  sense  complete  for  partial  cor¬ 
rectness.  A  crucial  axiom  provides  for  the  use  of 
auxiliary  variables,  which  are  added  to  a  parallel 
program  as  an  aid  to  proving  it  correct.  The  infor¬ 
mation  in  a  partial  correctness  proof  can  be  used  to 
prove  such  properties  as  mutual  exclusion,  freedom 
from  deadlock,  and  program  termination.  Tech¬ 
niques  for  verifying  these  properties  are  presented 
and  illustrated  by  application  to  the  dining 
philosophers  problem. 

Owicki76b 

Owieki,  S.  and  D.  Gries.  “An  Axiomatic  Proof  Tech¬ 
nique  for  Parallel  Programs  I.”  Acta  Informalica  6 

(1976),319-340. 

Abstract:  A  language  for  parallel  programming, 
with  a  primitive  construct  for  synchronization  and 
mutual  exclusion,  is  presented  Hoare 's  deductive 
system  for  proving  partial  correctness  of  sequential 
programs  is  extended  to  include  the  parallelism  de¬ 
scribed  by  the  language.  The  proof  method  lends 
insight  into  how  one  should  understand  and  present 
parallel  programs.  Examples  are  given  using  sev¬ 
eral  of  the  standard  problems  in  the  literature. 
Methods  for  proving  termination  and  the  absence  of 
deadlock  are  also  given. 

Cwicki82 

Owieki,  S.  and  L.  Lamport.  “Proving  Liveness 

Properties  of  Concurrent  Programs.”  ACM  Trans. 

Prog.  Lang,  and  Syst.  4,  3  (Oct.  1982),  455-495. 
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Abstract:  A  liveness  property  asserts  that  program 
execution  eventually  reaches  some  desirable  state. 
While  termination  has  been  studied  extensively, 
many  other  liveness  properties  are  important  for 
concurrent  programs.  A  fomal  proof  method, 
based  on  temporal  logic,  for  deriving  liveness 
properties  is  presented.  It  allows  a  rigorous  for¬ 
mulation  of  simple  informal  arguments.  How  to 
reason  with  temporal  logic  and  how  to  use  safety 
(invariance)  properties  in  proving  liveness  is 
shown.  The  method  is  illustrated  using,  first,  a 
simple  programming  language  without  synchroniza¬ 
tion  primitives,  then  one  with  semaphores.  How¬ 
ever,  it  is  applicable  to  any  programming  language. 

Pa  olini81 

Paolini,  P.  Abstract  Data  Types  and  Data  Bases. 
Ph  D.  Th.,  Computer  Science  Department,  Univer¬ 
sity  of  California,  Los  Angeles,  CA,  1981. 

Parnas72a 

Parnas,  D.L.  “On  the  Criteria  to  be  Used  in  Decom¬ 
posing  Systems  into  Modules.”  Comm.  ACM  15,  2 
(Dec.  1972),  1053-1058. 

Abstract:  This  paper  discusses  modularization  as  a 
mechanism  for  improving  the  flexibility  and  com¬ 
prehensibility  of  a  system  while  allowing  the  shor¬ 
tening  of  its  development  time.  The  effectiveness  of 
a  "modularization"  is  dependent  on  the  criteria 
used  in  dividing  the  system  into  modules.  A  system 
design  problem  is  presented  and  both  a  convention¬ 
al  and  unconventional  decomposition  are  described. 

It  is  shown  that  the  unconventional  decompositions 
have  distinct  advantages  for  the  goals  outlined.  The 
criteria  used  in  arriving  at  the  decomposition  are 
discussed.  The  unconventional  decomposition,  if 
implemented  with  the  conventional  assumption  that 
a  module  consists  of  one  or  more  subroutines,  will 
be  less  efficient  in  most  cases.  An  alternative  ap¬ 
proach  to  implementation  which  does  not  have  this 
effect  is  sketched. 

Pamas72b 

Parnas,  D.L.  “A  Technique  for  the  Specification  of 
Software  Modules.”  Comm.  ACM  15,  5  (May  1972), 
330-336. 

Abstract:  This  paper  presents  an  approach  to  writ¬ 
ing  specifications  for  parts  of  software  systems. 
The  main  goal  is  to  provide  specifications  suf¬ 
ficiently  precise  and  complete  that  other  pieces  of 
software  can  be  written  to  interact  with  the  piece 
specified  without  additional  information.  The  sec¬ 
ondary  goal  is  to  include  in  the  specification  no 
more  information  than  necessary  to  meet  the  first 
goal.  The  technique  is  illustrated  by  means  of  a 
variety  of  examples  from  a  tutorial  system. 


Pedersen89 

Pedersen,  J.S.  Software  Development  Using  VDM. 
Curriculum  Module  SEI-CM-16,  DTIC:  ADA 
235996,  Software  Engineering  Institute,  Carnegie 
Mellon  University,  Pittsburgh,  Pa.,  Dec.  1989. 

(From  Capsule  Description)  This  module  introduces 
the  Vienna  Definition  Method  (VDM)  approach  to 
software  development.  The  method  is  oriented 
toward  a  formal  model  view  of  the  sofware  to  be 
developed.  The  emphasis  of  the  module  is  on  for¬ 
mal  specification  and  systematic  development  of 
programs  using  VDM.  A  major  part  of  the  module 
deals  with  the  particular  specification  language  (and 
abstraction  mechanisms)  used  in  VDM 

Peterson81 

Peterson,  J.L.  Petri  Net  Theory  and  the  Modeling  of 
Systems.  Englewood  Cliffs,  NJ;  Prentice -Hall, 
1981. 

This  is  the  classic  book  covering  Petri  Nets  and 
their  use  in  modeling  of  concurrent  systems. 

Place90 

Place,  P.R.H.,  W.B.  Wood,  and  M.  Tudball.  Survey 
of  Formal  Specification  Techniques  for  Reactive 
Systems.  CMU/SHI-90-TR-5,  DTIC:  ADA  22374, 
Software  Engineering  Institute,  Carnegie  Mellon 
University,  Pittsburgh,  PA,  1990. 

Abstract:  Formal  methods  are  being  considered  for 
the  description  of  many  systems  including  systems 
with  real-time  constraints  and  multiple  concurrently 
executing  processes.  This  report  develops  a  set  of 
evaluation  criteria  and  evaluates  Communicating 
Sequential  Processes  (CSP),  the  Vienna  Definition 
Method  (VDM),  and  temporal  logic.  The  evaluation 
is  based  on  specifications,  written  with  each  of  the 
techniques,  of  an  example  avionics  system. 

Plotkin76 

Plotkin,  G.D.  “A  Power  Domain  Construction” 
SIAM  Journal  of  Computing  5,  3  (1976),  452-487. 

Abstract:  We  develop  a  powerdomain  construction 
?(•),  which  is  analogous  to  the  power  set  construc¬ 
tion  and  also  fits  in  with  the  usual  sum.  product  and 
exponentiation  constructions  on  domains.  The  de¬ 
sire  for  such  a  construction  arises  when  considering 
programming  languages  with  nondeterministic  fea¬ 
tures  or  parallel  features  treated  in  a  nondeter¬ 
ministic  way.  We  hope  to  achieve  a  natural,  fully 
abstract  semantics  in  which  such  equivalences  as  (p 
par  q)  =  (q  par  p)  hold.  Die  domain 
( D-vTruthvalues )  is  not  the  right  one.  and  instead 
we  take  the  (finitely)  generable  subsets  of  D  When 
D  is  discrete  they  are  ordered  in  an  elementwise 
fashion.  In  the  general  case  they  are  given  the 
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coarsest  ordering  consistent,  in  an  appropriate 
sense,  with  the  ordering  given  in  the  discrete  case. 

We  then  find  a  restricted  class  of  algebraic  induc¬ 
tive  partial  orders  which  is  closed  under  ?(•)  as 
well  as  the  sum,  product  and  exponentiation  con¬ 
structions.  This  class  permits  the  solution  of  recur¬ 
sive  domain  equations,  and  we  give  some  illustra¬ 
tive  semantics  using  ‘P(»). 

It  remains  to  be  seen  if  our  powerdomain  construc¬ 
tion  does  give  rise  to  fully  abstract  semantics,  al¬ 
though  such  natural  equivalences  as  the  above  do 
hold.  The  major  deficiency  is  the  lack  of  a  convinc¬ 
ing  treatment  of  the  fair  parallel  construct. 

Plotkin83 

Plotkin,  G.D.  “An  Operational  Semantics  for  CSP.” 
In  Formal  Description  of  Programming  Concepts  II, 
D.  Bjorner,  ed.  Amsterdam:  North-Holland,  1983, 
199-224. 

Abstract :  Hoare’s  CSP  is  used  to  illustrate  a  meth¬ 
od  employing  the  well-known  idea  of  labelled  transi¬ 
tion  systems  to  provide  operational  semantics  for 
programming  languages.  What  is  new  is  their 
specifications;  following  the  modem  emphasis  on 
structure  they  are  given  by  structural  induction  on 
abstract  syntax,  resulting  in  a  precise  but  intuitive 
semantics.  Most  of  CSP  is  treated  including  the 
arbitrary  nesting  of  parallel  commands  and  the 
failure  convention  when  communicating  with  a  ter¬ 
minated  process;  also  a  solution  to  the  library  prob¬ 
lem  is  proposed. 

Pnueli77 

Pnueli,  A.  “The  Temporal  Logic  of  Programs,” 
Eighteenth  Annual  Symposium  on  the  Foundations 
of  Computer  Science.  Long  Beach,  CA:  IEEE  Com¬ 
puter  Society,  Nov.  1977. 

Abstract:  A  unified  approach  to  program  verifi¬ 
cation  is  suggested,  which  applies  to  both  sequen¬ 
tial  and  parallel  programs.  The  main  proof  method 
suggested  is  that  of  temporal  reasoning  in  which  the 
time  dependence  of  events  is  the  basic  concept. 
Two  formal  systems  are  presented  for  providing  a 
basis  for  temporal  reasoning.  One  forms  a  for¬ 
malization  of  the  method  of  intermittent  assertions, 
while  the  other  is  an  adaptation  of  the  tense  logic 
system  and  is  particularly  suitable  for  reason¬ 
ing  about  concurrent  programs. 

Pnueli81 

Pnueli,  A.  “The  Temporal  Semantics  of  Concurrent 
Programs.”  Theoretical  Computer  Science  13 
0981),  45-60. 

Abstract:  The  formalism  of  Temporal  Logic  is  sug¬ 
gested  as  or.  appropriate  >ool  for  formalizing  the 
semantics  of  concurrent  programs.  A  simple  model 


of  concurrent  programs  is  presented  in  which  n 
processors  are  executing  concurrent  n  disjoint  pro¬ 
grams  under  a  shared  memory  environment.  The 
semantics  of  such  a  program  specifies  the  class  of 
state  sequences  which  are  admissible  as  proper  ex¬ 
ecution  sequences  under  the  program.  7  ,e  two 
main  criteria  which  are  required  are: 

•  Each  State  is  obtained  from  its  predeces¬ 
sor  in  the  sequence  by  exactly  one  proces¬ 
sor  performing  an  atomic  instruction  in  its 
process. 

•  Fair  Scheduling:  No  processor  which  is 
infinitely  often  enabled  will  be  indefinitely 
delayed. 

The  basic  elements  of  temporal  Logic  are  intro¬ 
duced  in  a  particular  logic  framework  DX.  The 
usefulness  of  Temporal  Logic  notation  in  describing 
properties  of  concur  rent  programs  is  demonstrated. 

A  construction  is  then  given  for  assigning  to  a  pro¬ 
gram  P  a  temporal  formula  W  (P)  which  is  true  on 
all  proper  execution  sequences  of  P.  In  order  to 
prove  that  a  program  P  possesses  a  property  R,  one 
has  only  to  prove  the  implications  W  (P)  c  R.  An 
example  of  such  proof  is  given.  It  is  then  demon¬ 
strated  that  specification  of  the  Temporal  character 
of  the  program 's  behavior  is  absolutely  essential  for 
the  unambiguous  understanding  of  the  meaning  of 
programming  constructs. 

Popek75 

Popek,  G.J.  and  C.S.  Kline.  “A  Verifiable  Protection 

System.”  ACM  SIGPLAN  Notices  10,  6  (June  1975), 

294-304. 

Abstract:  This  paper  reports  on  the  design  and 
implementation  of  the  UCLA  Virtual  Machine  Sys¬ 
tem,  a  multiuser  operating  system  base  that  has 
been  developed  to  provide  ultra  high  reliability  pro¬ 
tection  and  security.  Details  are  presented  of  the 
UCLA-VM  system,  a  prototype  of  which  now  exists. 
Concepts  which  have  influenced  its  structure  are 
discussed,  including  program  verification,  security- 
kernels,  virtual  machines,  virtual  memory,  and  the 
need  for  flexible  information  sharing  facilities.  A 
new  mechanism,  capability  faulting,  is  developed  in 
order  to  remove  much  of  the  virtual  memory  sup¬ 
port  from  the  security  kernel.  Flexible,  reliable 
control  of  sharing  is  obtained  by  extensions  to  sev¬ 
eral  of  these  concepts,  especially  through  the  use  of 
levels  of  kernels. 

Popek79 

Popek,  G.,  M.  Kampe,  C.  Kline,  A.  Stoughton, 

M.  Urban,  and  E.  Walton.  “UCLA  Secure  Unix.” 

National  Computer  Conference.  Montvale,  NJ: 

AFIPS,  1979,  355-364. 

(From  the  Introduction)  The  UCLA  Data  Secure 
Unix  [sic)  operating  system  is  intended  as  a  demon- 
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station  that  verifiable  data  security  with  general 
functionality  is  attainable  today  in  medium  scale 
computing  systems.  More  specifically,  the  UCLA 
system  has  the  characteristic  that  data  security,  the 
assurance  that  data  cannot  be  directly  read  or  modi¬ 
fied  without  specific  permission,  is  enforced  via  a 
limited  amount  of  kernel  software.  High  levels  of 
care  are  being  applied  to  demonstrate  that  the 
security  properties  of  that  software  are  correctly  im¬ 
plemented.  In  addition,  the  system  is  designed  so 
that  confinement  can  be  demonstrated  by  audit  of 
some  additional,  isolated  code. 

Razouk77 

Razouk,  R.R.  The  GMB  Simulator  System  Reference 
Manual.  Computer  Science  Department,  University 
of  California,  Los  Angeles,  CA,  July  1977. 

Razouk79 

Razouk,  R.R.,  M.  Vernon,  and  G.  Estrin. 
“Evaluation  Methods  in  SARA  —  The  Graph  Model 
Simulator.”  Proceedings  of  the  Conference  on  Simu¬ 
lation,  Measurement  and  Modeling  of  Computer 
Systems.  Washington,  DC:  IEEE  Computer  Society, 
Aug.  1979,  189-206. 

Abstract:  The  supported  methodology  evolving  in 
the  SARA  ( System  ARchitects’  Apprentice )  system 
creates  a  design  framework  on  which  increasingly 
powerful  analytical  tools  are  to  be  grafted.  Control 
flow  analyses  and  program  verification  tools  have 
shown  promise  However,  in  the  realm  of  the  com¬ 
plex  systems  which  interest  us  there  is  a  great  deal 
of  research  and  development  to  be  done,  before  we 
can  count  on  the  use  of  such  powerful  tools.  We 
must  always  be  prepared  to  resort  to  experiments 
for  evaluation  of  proposed  designs. 

This  paper  describes  a  fundamental  SARA  tool,  the 
graph  model  simulator.  During  top-down  refine¬ 
ment  of  a  design,  the  simulator  is  used  to  test  con¬ 
sistency  between  the  levels  of  abstraction.  During 
composition,  known  building  blocks  are  linked  to¬ 
gether  and  the  composite  graph  model  is  tested  rel¬ 
ative  to  the  lowest  top-down  model.  Design  of  test 
environments  is  integrated  with  the  multilevel  de¬ 
sign  process.  The  SARA  methodology  is  exemplified 
through  design  of  a  higher  level  building  block  to 
do  a  simple  FFT 

Razouk80 

Razouk,  R.R.,  M.  Vernon,  and  M.  Brewer. 
Control-Flow  Analyzer  Reference  Manual.  Comput¬ 
er  Science  Department,  University  of  California,  Los 
Angeles,  CA,  Feb.  1980. 


Razouk85a 

Razouk,  R.R.  and  C.V.  Phelps.  “Performance  Anal¬ 
ysis  Using  Timed  Petri  Nets."  In  Protocol  Specifi¬ 
cations,  Testing,  and  Verification,  IV,  Y.  Yemini, 
R.  Strom,  and  S.  Yemini,  eds.  Amsterdam:  North- 
Holland,  1985. 

Abstract:  Petri  Nets  have  been  successfully  used  to 
model  and  evaluate  the  performance  of  distributed 
systems.  Several  researchers  have  extended  the  ba¬ 
sic  Petri  Net  model  to  include  time,  and  have  dem¬ 
onstrated  that  restricted  classes  of  Petri  Nets  can  be 
analyzed  efficiently.  Unfortunately,  the  restrictions 
prohibit  the  techniques  from  being  applied  to  many 
interesting  systems,  e.g.,  communication  protocols 
This  paper  proposes  a  version  of  timed  Petri  Nets 
which  accurately  models  communication  protocols, 
and  which  can  be  analyzed  using  Timed  Rea¬ 
chability  Graphs.  Procedures  for  constructing  and 
analyzing  these  graphs  are  presented.  The  analysis 
is  shown  to  be  applicable  to  a  larger  class  of  Timed 
Petri  Nets  thar  previously  thought.  The  model  and 
the  analysis  technique  are  demonstrated  using  a 
simple  communication  protocol. 

Razouk85b 

Razouk,  R.R.  and  D.S.  Hirschberg.  ‘Tools  for  Effi¬ 
cient  Analysis  of  Concurrent  Software  Systems." 
Proceedings  of  SOFTFAIR  85  Conference  on  Soft¬ 
ware  Development  Tools,  Techniques  arid 
Alternatives,  Washington,  DC:  IEEE  Computer  So¬ 
ciety,  Dec.  1985, 192-198. 

Abstract:  The  ever  increasing  use  of  distributed 
computing  as  a  method  of  providing  added  comput¬ 
ing  power  and  reliability  has  sparked  interest  in 
methods  to  model  and  analyze  concurrent 
hardware/software  systems.  Efficient  automated 
analysis  tools  are  needed  to  aid  designers  of  such 
systems.  The  Distributed  Systems  Project  at  UCI 
has  been  developing  a  suite  of  tools  (dubbed  the 
P-NUT  system)  which  supports  efficient  analysis  of 
concurrent  software.  This  paper  presents  the  prin¬ 
ciples  which  guide  the  development  of  P-NUT  tools 
and  discusses  the  development  of  one  of  the  tools: 
the  Reachability  Graph  Builder  (RGB).  The  P-NUT 
approach  to  tool  development  has  resulted  in  the 
production  of  a  highly  efficient  tool  for  constructing 
reachability  graphs.  The  careful  design  of  data 
structures  and  associated  algorithms  has  signifi¬ 
cantly  enlarged  the  class  of  models  which  can  be 
analyzed. 

Reynold$72 

Reynolds,  J.C.  “Definitional  Interpreters  for  Higher- 
Order  Programming  Languages."  Proceedings  of  the 
ACM  Annual  Conference.  New  York:  ACM,  Aug. 
1972. 
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Abstract:  Higher-order  programming  languages 
(i.e.,  languages  in  which  procedures  or  labels  can 
occur  as  values )  are  usually  defined  by  interpreters 
which  are  themselves  written  in  a  programming 
language  based  on  the  lambda  calculus  (i.e.,  an  ap¬ 
plicative  language  such  as  pure  LISP).  Examples 
include  McCarthy's  definition  of  LISP,  Landin' s 
SECD  machine,  the  Vienna  definition  of  PL/I, 
Reynolds’  definitions  of  GEDANKEN,  and  recent 
unpublished  work  of  L.  Morris  and  C.  Wadsworth. 
Such  definitions  can  be  classified  according  to 
whether  the  interpreter  contains  higher-order  func¬ 
tions,  and  whether  the  order  of  the  application  (i.e., 
call  by-value  versus  call-by-name )  in  the  defined 
language  depends  on  the  order  of  application  in  the 
defining  language.  As  an  example,  we  consider  the 
definition  of  a  simple  applicative  programming  lan¬ 
guage  by  means  of  an  interpreter  written  in  a 
similar  language.  Definitions  in  each  of  the  above 
classifications  are  derived  from  one  another  by  in¬ 
formal  but  constructive  methods.  The  treatment  of 
imperative  features  such  as  jumps  and  assignment 
is  also  discussed. 

Ritchie74 

Ritchie,  D.M.  and  K.L.  Thompson.  “The  UNIX 
Time-Sharing  System.”  Comm.  ACM  17,  1  (July 
1974),  365-375. 

Abstract:  UNIX  is  a  general-purpose,  multi-user, 
interactive  operating  system  for  the  Digital  Equip¬ 
ment  Corporation  PDP-1 1/40  and  11/45  computers. 

It  offers  a  number  of  features  seldom  found  even  in 
larger  operating  systems,  including:  (1)  a  hierar¬ 
chical  file  system  incorporating  demountable 
volumes.  (7.)  compatible  file,  device,  and  inter¬ 
process  I/O:  (3)  the  ability  to  initiate  asynchronous 
processes;  (4)  system  command  language  selectable 
on  a  per-user  basis;  (5)  over  100  subsystems  includ¬ 
ing  a  dozen  languages.  This  paper  discusses  the 
nature  and  implementation  of  the  file  system  and  of 
the  user  command  interface. 

Robinson79 

Robinson,  L.  The  HDM  Handbook,  Volume  1:  The 
Foundations  of  HDM.  SRI  Project  4828,  Computer 
Science  Laboratory,  SRI  International,  Menlo  Park, 
CA,  June  1979. 

(From  the  Introduction)  HDM  provides  an  inte¬ 
grated  collection  of  languages  and  tools  that  aid  in 
the  software  development  process.  HDM  addresses 
many  of  the  aspects  of  die  general  software  problem 
—  namely  that  software  is  often  late,  too  costly, 
unreliable,  and  noncompliant  with  its 
requirements... 

In  developing  HDM,  we  have  selected  some  partic¬ 
ularly  useful  concepts  and  integrated  (item  into  a 
unified  approach  that  encourages  software  develop¬ 


ers  to  think  about  software  development  in  terms  of 
these  concepts.  This  approach  defines  a  system  as 
consisting  of  a  set  of  components  arranged  in  a  par¬ 
ticular  structure.  The  components  are  specified 
using  languages  developed  for  that  purpose  Some 
properties  of  the  specifications  can  be  evaluated  by 
on-line  tools;  others  can  be  measured  by  subjective 
evaluation.  The  languages  and  tools  of  HDM  have 
been  designed  to  enforce  its  concepts  and  to  realize 
its  mechanisms. 

This  volume  describes  the  basic  concepts  of  HDM 
The  stages  provide  a  suggested  ordering  of  system 
development.  Guidelines  for  the  use  of  HDM  are 
also  presented. 

Rolph 

Rolph,  S.  and  T.  Alfano.  Stalemate  by  Example. 
Burlington,  MA:  i-Logix,  date  unknown. 

This  book  shows  by  use  of  a  simplified,  but  real 
example  how  STATEMATE  might  be  used  to  de¬ 
sign  a  reactive  system.  (The  book  has  no  sign  of 
any  publication  date!) 

Rombach87 

Rombach,  H.D.  Software  Specification:  A 

Framework.  Curriculum  Module  SEI-CM-11,  Soft¬ 
ware  Engineering  Institute,  Carnegie  Mellon  Univer¬ 
sity,  Pittsburgh,  Pa„  Oct.  1987. 

(From  Capsule  Description)  This  module  provides  a 
framework  for  specifying  software  processes  and 
products.  The  specification  of  a  software  product 
type  describes  how  the  correspoding  products 
should  look.  The  specification  of  a  sofwtare  proc¬ 
ess  type  describes  how  the  corresponding  processes 
should  be  performed. 

Ruggiero79 

Ruggiero,  W„  G.  Estrin,  R.  Fenchel,  R.  Razouk, 
D.  Schwabe,  and  M.  Vernon.  “Analysis  of  Data 
Flow  Models  Using  the  SARA  Graph  Model  of 
Behavior.”  National  Computer  Conference. 
Montvale,  NJ:  AFIPS,  June  1979. 

Rushby91a 

Rushby,  J„  F.  von  Henke,  and  S.  Owre.  An  Intro¬ 
duction  to  Formal  Specification  and  Verification 
Using  EHDM.  CSL  Technical  Report.  SR1- 
CSL-91-02,  Computer  Science  Laboratory,  SRI  In¬ 
ternational,  Menlo  Park,  CA,  Aug.  1991. 

Abstract:  This  report  is  a  tutorial  on  formal  speci¬ 
fication  and  verification  using  EHDM  The  EHDM 
specification  language  is  very  expressive,  based  on 
a  strongly  typed  higher-order  logic,  enriched  with 
elements  of  the  Hoare  (relational)  calculus.  The 
type  system  provides  subtypes,  dependent  types,  and 
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certain  forms  of  type-polymorphism.  Modules  are 
used  to  structure  large  specifications  and  support 
hierarchical  development.  The  language  has  a 
complete  formal  semantic  characterization  and  is 
supported  by  a  fully  mechanized  specification  and 
verification  environment  that  has  been  used  to  de¬ 
velop  large  specifications  and  perform  very  hard 
formal  verifications. 


The  tutorial  uses  simple  examples  to  describe  the 
EHDM  language,  methodology,  and  tools.  The  first 
examples  illustrate  the  basic  ideas  of  specification 
and  theorem  proving  in  EHDM.  We  then  introduce 
the  ideas  of  testing  specifications,  of  horizontal  and 
vertical  hierarchy,  and  of  consistency  and  conser¬ 
vative  extension.  Later  chapters  cover  more  ad¬ 
vanced  topics  including  subtypes,  higher-order 
logic,  proofs  by  induction,  and  program  verification 
using  Hoare  logic.  The  tutorial  is  illustrated 
throughout  with  self-contained  examples  of  EHDM 
specifications  and  proofs,  all  of  which  have  been 
mechanically  checked. 


Rushby91b 

Rushby,  J.  and  F.  von  Henke.  Formal  Verification  of 
the  Interactive  Convergence  Clock  Synchronization 
Algorithm.  CSL  Technical  Report,  SRI-CSL-89-3R, 
Computer  Science  Laboratory,  SRI  International, 
Menlo  Park,  CA,  Aug.  199  i. 


Abstract:  We  describe  a  formal  specification  and  a 
mechanically  checked  verification  of  the  Interactive 
Convergence  Clock  Synchronization  Algorithm  of 
Lamport  and  Melliar-Smith  ....  In  the  course  of  this 
work,  we  discovered  several  technical  flaws  in  the 
analysis  given  by  Lamport  and  Melliar-Smith,  even 
though  their  presentation  is  unusually  precise  and 
detailed.  As  far  as  we  know,  these  flaws  (effecting 
the  main  theorem  and  four  of  its  five  lemmas)  were 
not  detected  by  the  "social  process"  of  informal 
peer  scrutiny  to  which  the  paper  has  been  subjected 
since  its  publication.  We  discuss  the  flaws  in  the 
published  proof  and  give  a  revised  presentation  of 
the  analysis  that  not  only  corrects  il  e  flaws  in  the 
original,  but  is  also  more  precised  a  d,  we  believe, 
easier  to  follow.  Th is  informal  presentation  was 
derived  directly  from  our  formal  specification  and 
verification.  Some  of  our  corrections  to  the  flaws  in 
the  original  require  slight  modifications  to  the  as¬ 
sumptions  underlying  the  algorithm  and  to  the  con¬ 
straints  on  its  parameters,  and  thus  change  the  ex¬ 
ternal  specification  of  the  algorithm. 


The  formal  analysis  of  the  Interactive  Convergence 
Clock  Synchronization  Algorithm  was  performed 
using  the  EHDM  formal  specification  and  verifica¬ 
tion  environment.  This  application  of  EHDM  pro¬ 
vides  a  demonstration  of  some  of  the  capabilities  of 
the  system. 


Rushby91c 

Rushby,  J.  Formal  Specification  and  Verification  for 
Critical  Systems:  Tools,  Achievements,  and 
Prospects.  Computer  Science  Laboratory,  SRI  Inter¬ 
national,  Menlo  Park,  CA,  Aug.  1991. 

Abstract:  Formal  specification  and  verificaiion  use 
mathematical  techniques  to  help  document,  specify, 
design,  analyze,  or  certify  computer  software  and 
hardware.  Mathematically-based  notation  can  pro¬ 
vide  specifications  that  are  precises  /sic]  and  un¬ 
ambiguous  and  that  can  be  checked  mechanically 
for  certain  types  of  error.  Formal  verification  uses 
theorem  proving  techniques  to  establish  consistency 
between  one  level  of  formal  specification  and 
another. 

This  paper  describes  some  of  the  issues  in  the  de¬ 
sign  and  use  of  formal  specification  languages  and 
verification  systems,  outlines  some  examples  of  the 
application  of  formal  methods  to  critical  systems, 
and  identifies  the  benefits  that  may  be  obtained 
from  this  technology. 

Scheld83a 

Scheid,  J.  Implementation  Specification. 
TM-73 15/000/00,  System  Development  Corpora¬ 
tion,  Santa  Monica,  CA,  1983. 

(From  the  Introduction)  The  Implementation  Speci¬ 
fication  provides  the  capability  for  the  user  to  ex¬ 
press  the  connection  between  an  abstract  Ina  Jo 
specification  and  the  implementation  of  it  in  a 
Higher-Order  Language  (HOL)  code. 

Scheld83b 

Scheid,  J.  The  Design  of  the  Ina  Jo  Verification  Con¬ 
dition  Generator  (VCG)  for  Modula. 
TM-7393/OOO/OO,  System  Development  Corpora¬ 
tion,  Santa  Monica,  CA,  1983. 

(From  the  Introduction)  This  document  contains  the 
functional  design  of  the  Ina  Jo  verification  con¬ 
dition  generator  (VCG)  for  the  Modula  I  program¬ 
ming  language.  Although  the  VCG  can  be  used 
only  for  programs  written  in  York  Modula  for 
PDP-1 1/Unix  [sic]  systems,  much  of  the  design  is 
also  applicable  to  other  compilers  /  languages  / 
operating  systems  /  computers.  One  reason  for  this 
partial  design  independence  is  the  use  of  a  modified 
version  of  Ina  Jo  (Inamod)  on  both  sides  of  the  Ina 
Jo/VCG  interface,  i.e.  in  the  implementation  speci¬ 
fications  and  imbedded  [sic]  in  the  Modula  code 
[sic]. 

Scheld86a 

Scheid,  J.,  S.  Anderson,  R.  Martin,  and  S.  Holtsbcrg. 
The  Ina  Jo  Specification  Language  Reference 
Manual.  TM-(L)-602 1/00 1/02,  SDC,  A  Burroughs 
Company,  Santa  Monica,  CA,  Jan.  1986. 
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Scheid86b 

Scheid,  J.  and  S.  Holtsberg.  Enhancements  to  For¬ 
mal  Development  Methodology  (FDM):  Ina  Jo 
Definition.  TM-7527/016/00,  SDC,  A  Burroughs 
Company,  Santa  Monica,  CA,  March  1986. 

Scheid89 

Scheid,  J.  and  S.  Holtsberg.  The  Ina  Jo  Specification 
Language  Reference  Manual.  TM-(L)-602 1/001/05, 
Unisys  Corporation,  Culver  City,  CA,  May  1989. 

(From  the  Introduction)  Ina  Jo  is  the  specification 
language  of  the  Formal  Development  Methodology 
(FDM).  This  reference  manual  describes  Ina  Jo  as 
it  is  implemented  in  Release  12.4  of  the  FDM  tools. 

Schmidt86 

Schmidt,  D.A.  Denotational  Semantics,  A  Method¬ 
ology  for  Language  Development.  Boston:  Allyn 
and  Bacon,  1986. 

This  book  presents  the  topic  of  denotational  seman¬ 
tics  from  an  engineering  standpoint,  focusing  on 
programming  language  description  and  implemen¬ 
tation.  Chapter  12  covers  denotational  semantics  of 
nondetenninism  and  concurrency. 

Schwabe85 

Schwabe,  D.  and  A.R.  Cavalli.  ‘Temporal  Logic 
Specification  of  a  Virtual  Ring  Lan  Access 
Protocol.”  In  Protocol  Specifications,  Testing,  and 
Verification,  IV,  Y.  Yemini,  R.  Strom,  and 
S.  Yemini,  eds.  Amsterdam:  North-Holland,  1985. 

Abstract:  This  paper  presents  the  use  of  temporal 
logic  for  the  specification  of  the  access  protocol  of 
a  local  area  network,  REDPUC,  developed  at  the 
Department  of  Informatics  of  the  Catholic  Univer¬ 
sity  in  Rio  de  Janeiro.  The  particular  temporal 
logic  system  used  allows  the  application  of  the  auto¬ 
mated  proof  techniques  developed ...  [by  Cavalli  et 
al/  The  protocol  described  here  exhibits  a  higher 
degree  of  complexity  than  other  protocols 
previously  described  in  the  literature,  especially  if 
one  considers  only  efforts  using  temporal  logic. 

SchwartzSI 

Schwartz,  R.L.  and  P.M.  Melliar-Smith.  ‘Temporal 
Logic  Specification  of  Distributed  Systems.”  Second 
International  Conference  on  Distributed  Computing 
Systems.  Washington,  DC:  IEEE  Computer  Society, 
April  1981,446-454. 

Abstract:  This  paper  describes  the  use  of  temporal 
logic  to  specify  protocols  for  distributed  network 
communications.  The  Alternating  Bit  protocol,  cho¬ 
sen  for  illustration,  provides  a  simple  yet  non-trivial 
example  of  the  method.  Temporal  logic  lends  a 


uniform  framework  in  which  to  specify  and  formally 
verify  both  safety  and  progress  (liveness)  properties 
o  f  the  protocol. 

Shostak82 

Shostak,  R.E.,  R.L.  Schwartz,  and  P.M.  Melliar- 
Smith.  “STP:  A  Mechanized  Logic  for  Specification 
and  Verification.”  In  Proceedings  of  the  Sixth  Con¬ 
ference  on  Automated  Deduction.  Lecture  Notes  in 
Computer  Science,  no.  1 38.  Berlin:  Springer- Ver- 
lag,  1982. 

(From  the  Introduction)  This  report  describes  a 
logic  and  proof  theory  that  has  been  mechanized 
and  successfully  applied  to  prove  nontrivial 
properties  of  a  fully  distributed  fault-tolerant  sys¬ 
tem.  We  believe  the  system  is  closer  to  achieving 
the  critical  balance  in  a  man-machine  interaction 
necessary  for  successful  application  by  users  other 
than  the  system  developers. 

STP  is  an  implemented  system  supporting  specifi¬ 
cation  and  verification  of  theories  expressed  in  an 
extension  of  multisorted  first-order  logic.  The  logic 
includes  type  parameterization  and  type  hierarchies. 
STP  support  includes  syntactic  checking  and  proof 
components  as  pan  of  an  interactive  environment 
with  a  certain  core  theory  that  comprises  a  set  of 
primitive  types  and  function  symbols,  and  extends 
this  theory  by  introducing  new  types  and  symbols, 
together  with  axioms  that  capture  the  intended  com¬ 
plete  decision  procedure  for  a  certain  syntactically 
characterizable  subtheory.  By  providing  aid  to  this 
component  in  the  form  of  the  selection  of  appro¬ 
priate  instances  of  axioms  and  lemmas,  the  user 
raises  the  level  of  competence  of  the  prover  to  en¬ 
compass  the  extended  theory  in  its  entirety.  As  a 
result  of  a  successful  proof  attempt  using  STP,  one 
obtains  the  sequence  of  intermediate  lemmas,  to¬ 
gether  with  the  axioms,  auxiliary  lemmas,  and  their 
necessary  instantiations,  which  lead  to  the  theorem. 
The  system  automatically  keeps  track  of  which  for¬ 
mulas  have  been  proved  and  which  have  not,  so  that 
the  user  is  not  forced  to  prove  lemmas  in  advance  of 
their  application.  The  system  also  monitors  the  in¬ 
cremental  introduction  and  modification  of  specifi¬ 
cations  to  maintain  soundness. 

Silverberg79 

Silverberg,  B.,  L.  Robinson,  and  K.N.  Levin.  The 
HDM  Handbook,  Volume  11:  The  Languages  and 
Tools  of  HDM.  SRI  Project  4828,  Computer  Sci¬ 
ence  Laboratory,  SRI  International,  Menlo  Park,  CA, 
June  1979. 

(From  the  Introduction)  In  this  volume,  we  present 
the  languages  and  tools  of  the  SRI  Hierarchical  De¬ 
velopment  Methodology  (HDM).  The  languages 
provide  a  way  of  recording  and  communicating  de- 
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cisions  made  throughout  stages  of  system  design, 
specification,  implementation,  and  verification.  The 
tools  assist  the  system  developer  during  this  devel¬ 
opment  process.  The  current  set  of  tools  is  used 
primarily  to  determine  whether  certain  well- 
formedness  and  consistency  criteria  are  satisfied. 

The  languages  of  HDM  are  intended  to  capture  the 
concepts  and  computational  model  described  in 
Volume  I.  SPECIAL  (SPECIfication  and  Assertion 
Language)  is  used  to  specify  modules  and  mapping 
functions.  HSL  (Hierarchy  Specification  Language) 
is  used  to  describe  the  structuring  of  modules  into 
machines,  and  machines  into  systems.  ILPL 
(Intermediate  Level  Programming  Language)  is 
used  to  record  module  implementation  decisions.  In 
addition,  the  final  implementation  code  is  written  in 
some  executable  programming  language  such  as 
Pascal,  Euclid,  Ada,  etc.  Such  implementation  lan¬ 
guages  could  also  be  considered  “languages  of 
HDM",  though  we  will  take  a  narrower  view  and 
restrict  our  attention  to  SPECIAL,  HSL,  and  HLPL. 

Smith85 

Smith,  M.K.  and  R.M.  Cohen.  “Gypsy  Verification 
Environment:  Status.”  ACM  Software  Eng.  Notes  10, 
4  (April  1985). 

(From  the  Introduction)  The  Gypsy  methodology  is 
an  integrated  system  of  methods,  languages,  and 
tools  for  designing  and  building  formally  verified 
software  systems.  The  methods  provide  fc»  (lie 
specification  and  coding  of  programs  that  can  be 
rigorously  verified  by  logical  deduction  always  to 
run  according  to  specification.  These  specification, 
programming,  and  verification  methods  dictated  the 
design  of  the  program  description  language 
Gypsy....  Gypsy  consists  of  two  intersection  com¬ 
ponents:  a  formal  specification  language  and  a  veri¬ 
fiable,  high  level  programming  language.  These 
component  languages  can  be  used  separately  or  col¬ 
lectively.  The  methodology  makes  use  of  the  Gypsy 
Verification  Environment  (GVE)  to  provide  auto¬ 
mated  support  The  GVE  is  a  large  interactive  sys¬ 
tem  that  maintains  a  Gypsy  program  description 
library  and  provides  a  highly  integrated  set  of  tools 
for  implementing  the  specification,  programming, 
and  verification  methods. 

Smith86 

Smith,  G.  and  D.V.  Schorre.  The  Interactive 
Theorem  Manual  (1TP)  User’s  Manual. 
TM-(L)-6889/000/006,  SDC,  A  Burroughs  Compa¬ 
ny,  Santa  Monica,  CA,  Dec.  1986. 

(From  the  Introduction)  SDC' s  Formal  Develop¬ 
ment  Methodology  (FDM)  is  an  integrated  method¬ 
ology  for  the  design,  specification,  implementation 
and  verification  of  software.  The  Ina  Jo  specifi¬ 
cation  language  forms  the  basis  for  this  method¬ 


ology,  and  formal  verification  of  the  specifications 
written  in  the  Ina  Jo  language  is  accomplished  by 
using  FDM’s  Interactive  Theorem  Prover  (ITP). 

Smyth78 

Smyth,  M  B.  “Powerdomains.”  J.  Comp,  and  Syst. 

Sci.  17  (1978),  23-36. 

(From  the  Introduction)  If  the  meaning  of  a  deter¬ 
ministic  program  may  be  considered  to  be  a  func¬ 
tion  from  D  to  D,  where  D  is  some  domain  of 
“states”,  then  it  would  seem  that  the  meaning  of  a 
nondeterministic  program  is  a  function  from  D  to 
2°,  or  perhaps  from  2°  to  2 P.  To  apply  the  meth¬ 
ods  of  fix-point  semantics,  then,  we  should  find 
some  way  to  construe  the  power  set  of  a  domain  as 
itself  a  domain,  with  a  suitable  ordering. 

Stein80 

Stein,  J.  and  D.V.  Schorre.  The  Interactive  Theorem 

Manual  (ITP)  User  Manual.  TM-(L)-68 89/000/001 , 

System  Development  Corporation,  Santa  Monica, 

CA,  Dec.  1980. 

(From  the  Introduction)  The  interactive  theorem 
prover  (ITP)  uses  the  rule  of  mathematical  logic  to 
generate,  with  the  active  and  occasionally  imagi¬ 
native  help  of  a  human  operator,  proofs  of  complex 
theorems  derived  from  specifications  written  in  the 
INA  JO  language.  These  proofs  would  be  ex¬ 
tremely  laborious  if  done  without  mechanized  tools 
as  the  theorems  are  usually  quite  long  and  many 
proof  steps  are  required.  The  ITP  uses  the  principle 
of  reductio  as  absurdum  (or  indirect  derivation)  to 
prove  the  theorems.  To  show  that  a  particular  set  of 
conditions  are  true,  the  assumption  is  made  that 
they  are  not  true.  From  this  assumption,  contradic¬ 
tions  (statements  that  negate  each  other)  are  de¬ 
rived;  therefore,  the  original  negated  statements  are 
contradictions  and  the  original  set  of  conditions  are 
true. 

Sunshine82 

Sunshine,  C.A.,  D.D.  Thompson,  R.W.  Erickson, 

S.L.  Gerhart,  and  D.  Schwabe.  “Specification  and 

Verification  of  Communication  Protocols  in  AF¬ 
FIRM  Using  State  Transition  Models.”  IEEE  Trans. 

Software  Eng.  SE-8 , 5  (1982),  460-489. 

Abstract:  It  is  becoming  increasingly  important 
that  communication  protocols  be  formally  specified 
and  verified.  This  paper  describes  a  particular  ap¬ 
proach — the  state  transition  model — using  a  collec¬ 
tion  of  mechanically  supported  specification  and 
verification  tools  incorporated  in  a  running  system 
called  AFFIRM.  Although  developed  for  the  speci¬ 
fication  of  abstract  data  types  and  the  verification 
of  their  properties,  the  formalism  embodied  in  AF¬ 
FIRM  can  also  express  the  concepts  underlying 
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slate  transition  machines.  Such  models  easily  ex¬ 
press  most  of  the  events  occurring  in  protocol  sys¬ 
tems,  including  those  of  the  users,  their  agent  proc¬ 
esses,  and  the  communication  channels.  The  paper 
reviews  the  basic  concepts  of  state  transition 
models  and  the  AFFIRM  formalism  and  methodol¬ 
ogy  and  describes  their  union.  A  detailed  example, 
the  alternating  bit  protocol,  illustrates  various 
properties  of  interest  for  specification  and  verifi¬ 
cation.  Other  examples  explored  using  this  for¬ 
malism  are  briefly  described  and  the  accumulated 
experience  is  discussed. 

The  paper  is  an  excellent  introduction  to  AFFIRM, 
and  a  demonstration  of  its  practical  utility  in  a 
realistic  problem  domain. 

Tanenbaum87 

Tanenbaum,  A.S.  Operating  Systems:  Design  and 
Implementation.  Englewood  Cliffs,  NJ:  Prentice- 
Hall,  1987. 

This  book  describes  operating  systems  in  general 
via  the  construction  of  MINIX,  a  UNIX  look-alike 
that  runs  on  1BM-PC  compatibles.  The  book  con¬ 
tains  a  complete  MINIX  manual  and  a  complete 
listing  of  its  C  code. 

Thompson81 

Thompson,  D.H.  and  R.W.  Erickson.  AFFIRM  Ref¬ 
erence  Manual.  USC  Information  Sciences  Institute, 
Marina  del  Rey,  CA,  Feb.  198!. 

Abstract:  Affirm  is  an  experimental  interactive 
system  for  the  development  of  specifications  and  the 
verification  of  abstract  data  types  and  algorithms. 
This  document  discusses  the  major  concepts  behind 
Affirm,  and  explains  the  purpose  and  use  of  each  of 
the  abstract  machines  comprising  the  structure  of 
the  system  as  seen  by  the  user. 

Vernon80 

Vernon,  M.,  W.  Overman,  and  R.  Razouk.  GMB 
PLI  Preprocessor  Reference  Manual.  Computer 
Science  Department,  University  of  California,  Los 
Angeles,  CA,  Jan.  1980. 

Wegner68 

Wegner,  P.  Programming  Languages,  Information 
Structures,  and  Machine  Organization.  New  York: 
McGraw-Hill,  1968. 

This  book  introduces  the  concept  of  Information 
Structure  Model  and  uses  it  to  describe  program¬ 
ming  Languages  and  computers. 


Wegner70 

Wegner,  P.  “Three  Computer  Cultures:  Computer 

Technology,  Computer  Mathematics,  and  Computer 

Science.”  In  Advances  in  Computers.  New  York: 

Academic  Press,  1970,  7-78. 

Abstract:  Computers  have  proved  so  useful  as  sci¬ 
entific  and  technical  tools  that  computer  science  is 
widely  regarded  as  a  technological  discipline  whose 
purpose  is  to  create  problem-solving  tools  for  other 
disciplines.  Within  computer  science  there  is  a 
group  of  theoreticians  who  build  mathematical 
models  of  computational  processes.  Yet  computer 
science  is  neither  a  branch  of  technology  nor  a 
branch  of  mathematics.  It  involves  a  new  way  of 
thinking  about  computational  schemes  that  is  partly 
technological  and  partly  mathematical,  but  contains 
a  unique  ingredient  that  differs  qualitatively  from 
those  of  traditional  disciplines.  This  paper  il¬ 
lustrates  the  special  quality  which  distinguishes 
computer  science  from  technology  and  mathematics 
by  means  of  examples  from  the  emerging  theory  of 
programming  languages. 

Wegner72 

Wegner,  P.  “The  Vienna  Definition  Language.” 

ACM  Computing  Surveys  4,  1  (March  1972),  5-63. 

Abstract:  The  Vienna  Definition  Language  (VDL) 
is  a  programming  language  for  defining  program¬ 
ming  languages.  It  allows  us  to  describe  precisely 
the  execution  of  the  set  of  all  programs  of  a  pro¬ 
gramming  language.  However,  the  Vienna  Defini¬ 
tion  Language  is  important  not  only  as  one  defini¬ 
tion  technique  among  many  others  but  as  an  illus¬ 
tration  of  a  new  informution-stnicture-oriei.ted  ap¬ 
proach  to  the  study  of  programming  languages. 
This  paper  may  be  regarded  as  a  case  study  in  the 
information  structure  modeling  of  programming 
languages,  as  well  as  an  introduction  to  a  specific 
modeling  technique.... 

Wing89 

Wing,  J.M.  and  M.  Nixon.  “Extending  Ina  Jo  with 

Temporal  Logic.”  IEEE  Trans.  Software  Eng. 

SE-15, 2  (Feb.  1989),  181-197. 

Abstract:  Toward  the  overall  goal  of  putting  for¬ 
mal  specifications  to  practical  use  in  the  design  of 
large  systems,  we  explore  the  combination  of  two 
specification  methods:  using  temporal  logic  to  spec¬ 
ify  concurrency  properties  and  using  an  existing 
specification  language,  Ina  Jo,  to  specify  junctional 
behavior  of  nondeterministic  systems.  In  this  paper, 
we  give  both  informal  and  formal  descriptions  of 
both  current  Ina  Jo  and  Ina  Jo  enhanced  with  tem¬ 
poral  logic.  We  include  details  of  a  simple  example 
to  demonstrate  the  use  of  the  proof  system  and  de¬ 
tails  of  an  extended  example  to  demonstrate  the  ex¬ 
pressiveness  of  the  enhanced  language.  We  discuss 
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at  length  our  language  design  goals,  decisions,  and 
their  implications.  The  appendix  contains  a  list  of 
axioms,  rules  of  inference,  derived  rules,  and 
theorem  schemata  for  the  enhanced  formal  system. 

Wirth66 

Wirth,  N.  and  H.  Weber.  “EULER:  A  Generalization 
of  ALGOL  and  its  Formal  Definition.’’  Comm.  ACM 
9,  1  &  2  (January  &  February  1966),  13-23  &  89-99. 

Abstract:  A  method  for  defining  programming  lan¬ 
guages  is  developed  which  introduces  a  rigorous 
relationship  between  strucr^e  and  meaning.  The 
structure  of  a  language  is  defined  by  a  phrase  struc¬ 
ture  syntax,  the  meaning  in  terms  of  the  effects 
which  the  execution  of  a  sequence  of  interpretation 
rules  exerts  upon  a  fixed  set  of  variables,  called  the 
Environment.  There  exists  a  one-to-one  correspon¬ 
dence  between  syntactic  rules  and  interpretation 
rules,  and  the  sequence  of  executed  interpretation 
rules  is  determined  by  the  sequence  of  correspond¬ 
ing  syntactic  reductions  which  constitute  a  parse. 
The  individual  interpretation  rules  are  explained  in 
terms  of  an  elementary  and  obvious  algorithmic 
notation,  A  constructive  method  for  evaluating  a 
text  is  provided,  and  for  certain  decidable  classes  of 
languages  their  unambiguity  is  proved.  As  an  ex¬ 
ample.  a  generalization  of  ALGOL  is  described  in 
full  detail  to  demonstrate  that  concepts  like  block- 
structure,  procedures,  parameters,  etc.  can  be  de¬ 
fined  adequately  and  precisely  by  this  method 

Wolper82 

Wolpcr,  P.  “Specification  And  Synthesis  of  Commu¬ 
nicating  Processes  Using  an  Extended  Temporal 
Logic."  Conference  Record  Ninth  Annual  ACM  Sym¬ 
posium  cn  Principles  of  Programming  Languages. 
New  York:  ACM,  Jan.  1982,  20-33. 

Abstract:  We  apply  an  Extended  Propositional 
Temporal  Logic  (EPTL)  to  the  specification  and 
synthesis  of  the  synchronization  part  of  communi¬ 
cating  processes.  To  specify  a  process,  we  give  an 
EPTL  formula  that  describes  its  sequence  of  com¬ 
munications.  The  synthesis  is  done  by  constructing 
a  model  of  the  given  specifications  using  a  tableau¬ 
like  satisfiability  algorithm  for  the  extended  tem¬ 
poral  logic.  This  model  can  then  be  interpreted  as 
a  program . 


Woodcoc:;87 

Woodcock,  J.C.P.  ‘Transaction  Processing  Primi¬ 
tives  and  CSP.”  IBM  Journal  of  Research  and  De¬ 
velopment  31,  5  (1987),  535-545. 


Abstract:  Several  primitives  for  transaction  pro 
essing  systems  are  developed  using  the  notations 
Communicating  Sequential  Processes  The  a, 
pmach  taken  is  to  capture  each  requireme 


separately,  in  the  simplest  possible  context  The 
specification  is  then  the  conjunction  of  all  these  re¬ 
quirements.  As  each  is  developed  as  a  predicate 
over  traces  of  the  observable  events  in  the  system,  it 
is  also  implemented  as  a  simple  communicating 
processs:  the  implementation  of  the  enure  system  ts 
then  merely  the  parallel  composition  of  these  proc¬ 
esses.  The  laws  of  CSP  are  then  used  to  transform 
'he  system  to  achieve  the  required  degree  of  concur¬ 
rency,  to  make  it  suitable  for  execution  in.  a 
multiple-tasking  system,  for  example.  Finally,  there 
is  a  discussion  how  state-based  systems  may  be 
developed  using  this  approach  together  with  some 
appropriate  notation  for  specifying  and  refining 
data  structures  and  operation  upon  them  and  of 
how  the  system  may  be  implemented.  This  work  is 
intended  as  a  case  studs  in  the  use  of  CSP 

Woodward79 

Woodward,  J.  “Applications  for  Multilevel  Secure 
Operating  Systems.”  National  Computer 
Conference.  Montvale,  NJ:  AF1PS,  1979,  319-328. 

(From  the  Introduction)  The  need  for  secure  com¬ 
puter  systems  has  been  identified  in  many  areas  of 
DoD  operations,  but  in  the  past  these  systems  have 
not  been  built  in  a  secure  manner  because  a  secure 
operating  system  on  which  to  run  has  not  existed. 
Now  that  venfiably  secure  microcomputer  operat¬ 
ing  systems  are  becoming  a  reality,  ipplicatians  for 
secure  systems  arc  becoming  more  clearly  thought- 
out,  designed  and  implemented.  This  paper  surveys 
some  proposed  DoD  and  non  DoD  secure  computer 
applicauons. 

Yu90 

Yu,  C.-F.  and  V.D.  Gligor.  “A  Specification  and 
Verification  Method  for  Preventing  Denial  of 
Service.”  IEEE  Trans.  Software  Eng.  SE-16,  6 
(1990),  581-592. 

Abstract:  In  this  paper,  we  present  a  specification 
and  verification  method  for  preventing  denial  of 
service  in  the  absence  of  failures  and  of  integrity 
violations.  We  introduce  the.  notion  of  "user 
agreements"  and  argue  that  lack  of  specifications 
for  these  arguments  and  for  simultaneity  conditions 
makes  it  impossible  to  demonstrate  dcnial-of- 
servir.e  prevention,  in  spite  of  demonstrahh  fair  ser¬ 
vice  access.  We  illustrate  the  use  of  this  method 
with  an  example  and  explain  whs  current  methods 
for  specification  and  verification  of  safety  and  Inc- 
ness  properties  of  concurrent  programs  do  not 
handle  this  problem.  The  proposed  .specification 
and  verification  method  is  meant  to  augment  cur¬ 
rent  methods  for  secure  system  design 
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Zave72 

Zave,  P.  “An  Operational  Approach  to  Requirements 

Specification  for  Embedded  Systems.”  IEEE  Trans. 

Software  Eng.  SE-8,  3  (1972),  250-269. 

Abstract:  The  approach  to  requirements  specifi¬ 
cation  for  embedded  systems  described  in  this  paper 
is  called  'operational'  because  a  requirements 
specification  is  an  executable  model  of  the  proposed 
system  interacting  with  its  environment.  The  ap¬ 
proach  is  embodied  by  the  language  PAISLey. 
which  is  motivated  and  defined  herein.  Embedded 
systems  are  characterized  by  asynchronous  paral¬ 
lelism,  even  at  the  requirements  level;  PAISLey 
specifications  are  constructed  by  interacting  proc¬ 
esses  so  that  this  can  be  represented  directly.  Em¬ 
bedded  systems  are  also  characterized  by  urgent 
performance  requirements,  and  PAISLey  offers  a 
formal,  but  intuitive  treatment  of  performance. 

Zave87a 

Zave,  P.  PAISLey  User  Documentation,  Volume  I: 

REFERENCE  MANUAL  Computer  Technology 

Research  Laboratory,  AT&T  Bell  Laboratories, 

1987. 

Zave87b 

Zave,  P.  PAISLey  User  Documentation,  Volume  2: 

TUTORIAL  Computer  Technology  Research  Labo¬ 
ratory,  AT&T  Bell  Laboratories,  1987. 

(From  Prologue)  PAISLey  is  an  executable  specifi¬ 
cation  language.  It  is  fully  formal  and  can  be  ex¬ 
ecuted  by  an  interpreter,  just  like  any  programming 
language.  But  it  is  also  meant  to  be  as 
implementation-independent  as  possible,  so  that  it 
can  describe  the  required  properties  and  behavior  of 
a  digital  system  without  constraining  how  those 
properties  and  behavior  are  implemented. 

Zave87c 

Zave,  P.  PAISLey  User  Documentation,  Volume  3: 

CASE  STUDIES.  Computer  Technology  Research 

Laboratory,  AT&T  Bell  Laboratories,  1987. 

(From  the  Introduction)  The  purpose  of  this  volume 
of  documentation  is  to  provide  examples  of  PAIS- 
I.ey  specifications.  There  are  plenty  of  examples  in 
the  tutorial,  but  the  specifications  in  this  volume  are 
different  in  two  important  ways:  (1)  Most  of  the 
examples  in  the  tutorial  are  fragments  of  specifi¬ 
cations  selected  to  illustrate  particular  points  about 
PAISLey  The  specifications  here  are  all  described 
in  their  entirety,  and  they  are  presented  so  as  to 
simulate  the  mental  processes  that  created  them  (2) 

I  made  up  all  the  examples  in  the  tutorial  by  myself, 
with  no  outside  constraints  The  case  studies  are 
exactly  the  opposite — each  specification  solves  a 
problem  that  came  from  somewhere  else,  and  I  was 


forced  to  confront  its  difficulties  rather  than  avoid 
or  change  them. 

The  case  studies  fit  into  two  major  categories, 
“Academic  Problems”  are  all  relatively  simple,  rela¬ 
tively  unrealistic  problems  that  have  been  posed  for 
the  benefit  of  researchers.  Because  of  their  simplic¬ 
ity,  they  are  solved  in  great  detail  “Real  Systems” 
aie  just  that — system-development  projects  on 
which  PAISLey  has  been  used  Due  to  their  sizes 
the  specifications  of  real  systems  are  described  in 
general  rather  than  presented  in  detail 

Zave91 

Zave,  P.  “An  Insider’s  Evaluation  of  PAISLey.” 

IEEE  Trans.  Software  Eng.  17,  3  (March  1991), 
212-225. 

Abstract:  PAISLey  is  an  executable  specification 
language,  accompanied  by  specification  methods, 
analysis  techniques,  and  software  tools,  it  was  the 
subject  of  a  long-term  research  project,  llie  paper 
also  discusses  research  methods— both  how  the 
results  were  obtained,  and  how  the  project  might 
have  been  improved. 
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Tables  and  Figures 

This  section  contains  all  the  Tables  and  Figures  cited  in  the  text  of  the  module. 


Below,  all  distinct  symbols  are  assumed  to  be  unequal. 
Also,  t  is  taken  to  represent  a  hidden  event  also  in  CSP. 


Figure  1 
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Approaches  that  can  be  used 
to  prove  Properties  about  Programs 
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